the block diagrams of fig1 and 2 , and the flow chart of fig3 are an architectural overview of a preferred embodiment of a processor according to the present invention . the instruction fetcher 9 ( see fig2 and 3 ) preferably is coupled to a well - known instruction cache memory ( not shown ), and receives instructions 8 from the cache memory . among other functions , the fetcher 9 performs a &# 34 ; throttling &# 34 ; function . for example , if an instruction cannot be fetched from the instruction cache , then the fetcher 9 operates to bring an instruction from the main instruction memory ( not shown ) for transfer 100 to the instruction cache . once in the cache the instruction is fetched 102 . other examples of &# 34 ; throttling &# 34 ; functions performed by the fetcher 9 include managing instructions that require multiple clock cycles to dispatch , and managing instructions that cannot be fetched for some reason , for example , identification codes that are not available for assignment to an instruction 103 . as shown in fig2 the fetcher 9 supplies the dynamic register file 11 with the instructions fetched from cache . as the instructions 8 are fetched from cache , they are assigned 105 an identification code 29 , or id , by a counter ( not shown ) which assigns strictly sequential id values to each instruction that is fetched in the order fetched . these sequential ids contain a &# 34 ; color &# 34 ; bit which is the most significant bit , and is used for magnitude comparisons . by comparing the color bits , and , if necessary , the magnitudes of two instruction ids , the instruction fetched earlier can be determined . this provides an &# 34 ; age &# 34 ; comparison between two instructions , that is , it provides the relative order of when the instructions 8 were fetched from memory . as shown in fig2 the fetcher 9 also manages branch execution in a manner so that the fetcher 9 does not stop if a branch cannot be executed . for a branch to be executed , it must have valid condition codes 109 . the condition codes are set by instructions that modify the condition codes . thus , at the time when an instruction that modifies condition codes is dispatched , the fetcher 9 invalidates 117 a condition code register by putting a locked bit on it . the fetcher stores the id of the instruction that locked the condition code . the condition code stays locked until that instruction finishes execution and updates 113 the condition code register , thereby unlocking 115 the condition code . the content of the condition code register is termed &# 34 ; insane &# 34 ; herein when it does not reflect the state of the processor when updated sequentially , like the register file and memory . for the time when the condition codes are locked 117 , there is an instruction that indicates the need to modify the condition code . this prevents a following branch from using the condition code to make a decision . therefore , the fetcher puts such a following branch instruction in branch shelver 13 together with the id of the instruction that locked the condition code 112 . only the result of that locking instruction provides valid condition codes for the branch . in the branch shelver 13 , the branch instruction waits until the condition codes become available , i . e ., the branch instruction waits until the instruction that locked the condition codes completes execution and updates the condition codes . when a branch is shelved , the fetcher 9 will decide 110 , based on prediction bits , which direction down the instruction stream to proceed from that location , in other words , the most probable direction for continued execution of the program . the fetcher 9 will continue to fetch instructions &# 34 ; on speculation &# 34 ; along the predicted path . when the condition codes that a shelved branch instruction is waiting on become valid , then the branch decision is re - evaluated and compared 115 with the initial decision . if that comparison indicates that the branch was properly executed , it is removed 122 from the shelf . if the decisions are different on comparison 118 , the predicted decision was wrong and the processor must proceed along another not predicted branch . therefore , the program must resume execution from the branch instruction in another direction . for the processor to change direction following an incorrectly predicted branch decision 118 , the processor must be restartable at any point . for example , assume that there are n instructions allowed in the processor and that there are instructions which are fetched , but not executed . the processor must be able to restart with any instruction that is in the dynamic register file , i . e ., any instruction that has not updated the state of memory yet . that function , called restarting , is accomplished with the help of a program counter file , herein termed the &# 34 ; sane &# 34 ; program counter file 15 , which is an n - entry register file that contains the addresses of the instructions in the dynamic register file 11 , indexed by their ids . if the processor needs to restart by re - fetching a branch instruction , the id of the branch is used to index into the sane program counter file 15 and obtain its program counter 119 . that program counter is used to restart the processor from that point forward . in the case 118 when the branch was predicted incorrectly , some number of instructions were put into the execution stream and may have generated results which are in the dynamic register file 11 , but have not yet updated the register file 17 . they have not been allowed to reach completion by the sane state controller 19 because they are speculative . upon determination that a branch was incorrectly predicted , a flushing mechanism flushes 119 from the dynamic register file 11 all instructions and their results that were executed in reliance on the incorrect prediction . the flushing operation is described in conjunction with fig1 . the sane state controller 19 receives from the branch shelver 13 the id of the shelved branch instruction , or in the case of multiple shelved branches , the id of the oldest of all the shelved branches ( as determined by the order in which they were fetched ). the sane state controller 19 does not allow instructions which have an id that is more recent than the id of the oldest shelved branch to update the state of the processor , and therefore stops the completion of instructions at that point . this enables the processor to maintain its sane condition by not allowing the speculative results to alter the state of the processor . the processor may also restart after it encounters a trap condition or an external interrupt . the processor includes trap logic 21 which provides the states of the processor at the point of encountering a trap condition . the id of the trapping instruction is used to obtain the program counter from the sane program counter file 15 . the trap is not responded to until the trapping instruction becomes the oldest in the dynamic register file , in other words until all previously fetched instructions have updated the status of the processor . then all other instructions are flushed from the dynamic register file . for interrupts , the id of the oldest instruction that will next update the status of the processor is used to obtain the program counter . more recent instructions are flushed . another function of the fetcher 9 is serialization . some instructions cannot modify the state of the processor unless all the instructions prior to them have been executed ( the &# 34 ; serialization process &# 34 ; herein ). when such an instruction is encountered , the fetcher 9 stops fetching and waits until all previously fetched instructions have completed their execution . once there is not an unexecuted fetched instruction left in the processor , the fetcher will then let that instruction go to execution . when the instruction requiring serialization finishes modifying the state of the processor , fetching resumes . the dynamic register file 11 holds all non - branch instructions pending within the processor . every entry in the dynamic register file 11 is a place holder for an instruction . as shown in fig2 the dynamic register file 11 contains the results 31 of execution of the instruction , and includes locker id one 23 and locker id two 25 , an instruction field 27 which indicates what instruction is to be performed , and an id field 29 which is the tag of the instruction . two lockers 23 , 25 are included because instructions typically require two operands to execute . thus , one locker is provided for each possible operand required for an execution of an instruction . the dynamic register file 11 is controlled by an instruction scheduler 33 and a memory scheduler 35 . these two schedulers 33 , 35 perform the resource checking and data flow scheduling to create a data flow stream out of dynamic register file 11 . the resource checking determines if the operands needed by an instruction in the dynamic register file 11 are available and if so , where they are located . if they are available , the operands may be located in the dynamic register file 11 or in the register file 17 . a required operand will be in the dynamic register file if it resulted from a previously executed , but not completed instruction . the required operand will be in the register file 17 if the instruction that generated the operand was allowed to complete earlier and transferred its results to the register file 17 . in the worse case , the operand is not available because the result that will form the required operand has not been generated , i . e ., the operand is locked . the two locker fields 23 , 25 are used to identify , by id 29 , what instruction will create the result that will form an operand required by an instruction . when an instruction is executed , the result of that execution is written into the dynamic register file 11 in the result field 31 . results 31 in the dynamic register file 11 then can be used by more recently fetched instructions for execution . when the instructions reach the output 39 of the dynamic register file 11 by being oldest , they are written into the register file 17 under control of the sane state controller 19 . thus , the dynamic register file 11 acts as an instruction place holder for each non - branch instruction . instructions enter the dynamic register file 11 from the instruction fetcher 9 of the processor and the instructions remain in the dynamic register file 11 until they are oldest and are ready to update the register file 17 . the oldest instruction with no trap condition can be written to the register file 17 or to memory . the results 31 in dynamic register file 11 have a register address ( rz ) 41 which designates the register to which results will be written , if the instruction updates the register file 17 . for memory store instructions , rz is used to address the register file 17 for source data to be written to memory . the dynamic register file 11 also performs a register scoreboarding function . in a conventional register scoreboard method , there is a single valid bit associated with each register number . when an instruction is fetched that writes to a register , the valid bit for that register is set to invalid . execution of the fetched instruction updates that register , and the valid bit is reset to valid again . in contrast , in our system the dynamic register file 11 provides the register scoreboarding function by checking the operands against the register address fields 41 of all other entries at the time the instruction is placed into the dynamic register file 11 . when an instruction is placed into dynamic register file 11 , its register address 41 is considered to be locked until that result is actually made available . this process is shown in fig7 . as shown , when an instruction 701 is written into the dynamic register file 11 from the fetcher 9 , the operand register numbers are compared 702 to the register address field of every older instruction . if any match is found , the result field of the youngest such matching instruction is examined . if the result of execution of the matching instruction is not available 704 in the dynamic register file 11 , then the instruction is not runnable . if matching occurs and the result field of the youngest matching instruction is available , then the instruction can be sent to execution with its required operands obtained from the corresponding dynamic register file result field 705 . if no matching occurs , the instruction can be sent to execution 706 with its operands obtained from the register file 17 rather than the dynamic register file 11 . thus , an instruction is considered shelved and not sent to execution when its operands will be affected or modified by an unexecuted older instruction . the instruction scheduler 33 includes logic that determines which instructions should be run , if any . among the information about instructions examined by the instruction scheduler to determine whether the instruction should be executed is the locker information and instruction id . from this information , the instruction scheduler 33 picks the instructions most ready to run . the locker valid bits indicate to the instruction scheduler 33 that all of the operands necessary to execute an instruction are now in the dynamic register file 11 or in the register file 17 . if the ready bits of an operand are set , the instruction is considered executable . the instruction scheduler picks the oldest runnable instructions for which there are sufficient execution resources available . because the dynamic register file 11 provides a queue between the instruction fetch and execution issue stages , it smooths temporary imbalances between the fetcher 9 arrival rate and the execution service rate . if the arrival rate temporarily exceeds the service rate , then the queue will grow . to maintain a limit on the queue size based on the fetcher rate , the execution bandwidth ( i . e ., the number of parallel execution streams that can receive instructions from the dynamic register file 11 ) is higher than the fetcher bandwidth . additional execution bandwidth is also important because anytime an instruction is fetched and shelved and the dynamic register file has no instructions ready for execution , there is no instruction going into execution in that cycle . when that instruction subsequently becomes executable , if there were only one execution unit , then an execution cycle would necessarily be allocated to that instruction , and a newly fetched instruction must be shelved , degrading performance . in our system , however , at the time a shelved instruction goes to execution , it can be sent via the multiplexers 53 and 55 to an additional execution unit 47 , while the first execution unit 45 , via the multiplexers 49 and 51 executes newly - arriving instructions . this permits parallel execution of newly - fetched instructions with older instructions sent to execution from the dynamic register file 11 . of course , more than two execution units can be employed if necessary . the memory scheduler 35 shown in fig2 schedules the memory load instructions using the process shown in fig5 . the first step of a memory load operation is the generation of memory address . the address is placed in the result field 31 of dynamic register file 11 and compared 501 with the memory addresses of older store instructions that may be in the dynamic register file 11 via the domain check 59 . the result of the comparison indicates if the load operation is &# 34 ; safe &# 34 ; 515 , 517 , &# 34 ; unsafe &# 34 ; 518 , or &# 34 ; imprecise &# 34 ; 521 . &# 34 ; safe &# 34 ; means that there are no older stores to memory in the dynamic register file 11 whose memory address matches the memory address of the load operation and no older stores to memory whose addresses are still unknown . &# 34 ; unsafe &# 34 ; means that an older store to memory exist in the dynamic register file 11 whose address is known and matches the memory address of the load operation . &# 34 ; imprecise &# 34 ; means that there exist one or more older stores whose addresses have not yet been placed in the result field 31 of the dynamic register file 11 . only in the safe case can the load be sent to memory . if a memory load is unsafe the load cannot be sent to memory until all older store instructions with matching addresses have been sent . an imprecise load instruction must wait until the addresses for all older store instructions have been calculated , at which time it becomes either safe or unsafe . the domain checker 59 thus accomplishes essentially the same function for memory loads as the locking check does for register loads . once the load has been sent to memory , and memory returns the data 61 , the data is written into the result field 31 for that load instruction . once the instruction becomes the oldest , then it will be allowed to update the register file 17 . for memory stores , the result of calculating the store address is placed in the result field 31 of the dynamic register file 11 . when the memory store instruction is oldest , then the address 57 and the store data 63 are sent to memory . the store data 63 is read from the register file 17 which is addressed with the register address field 41 of the dynamic register file 11 . the store data 63 is known to be in the register file 17 because when the store instruction is sent to memory , every previous instruction has completed execution and transferred to the register file 17 . thus , the domain checker and the load scheduler permit loads to be sent to memory as soon as possible in case their results are needed by newer instructions . memory stores are sent in order so the memory is always in a sane state . the dynamic register file 11 and the register file 17 , and the dynamic register file 11 and the system memory have the same relative relationship in that the system memory and the register file 17 are always in sane condition . the dynamic register file 11 contains future results that can be used by newer instructions with the effect of &# 34 ; caching &# 34 ; results of neighboring instructions for possible use as operands for new instructions . the process for updating the register file 17 is summarized in fig8 . updates of the register file 17 occur when instructions are oldest . the oldest results are looked at to determine if they are ready to update 801 the register file 17 . if there are no trap conditions 802 indicated by the trap logic 21 , the results are written into the register file 17 using the register address 41 as an address , and the result field 31 as the data , under the control of the sane state controller 19 . when an instruction becomes oldest and has a trap 803 condition , it is prevented from updating the register file 17 or memory . a trap indication flag 65 ( see fig2 ) signals the trap logic 21 to handle the trap . in this way , traps are resolved in strict sequential order . if an instruction that came from execution generates a trap condition , the instruction might or might not have been in strict sequential order so its results are placed in the dynamic register file 11 together with the trap condition . the processor will not operate on the trap because that instruction may not have been next to complete sequentially . thus , if while the instruction is waiting in dynamic register file 11 to become the oldest and be transferred into the register file 17 , another instruction trap ( which happens to be older than the waiting instruction ) occurs , this other trap will be responded to first , thereby assuring that traps are serviced in sequential order . the sane state controller 19 maintains the update of register file 17 and memory in the order that is consistent with the order of instructions . the sane state controller 19 maintains a scoreboard of fetched instructions and their state of readiness to &# 34 ; retire ,&# 34 ; i . e ., to update the registers of memory . when instructions are ready to retire , the sane state controller 19 is signalled by a ready flag , as illustrated in fig2 . the sane state controller will retire an instruction just when it is ready to retire and all older instructions in the dynamic register file are also being retired , and none of those instructions has a trap condition . the number of update ports into the register file 17 is higher than the number of instructions that are fetched per cycle because of the queuing effect of the dynamic register file 11 . the dynamic register file 11 also provides for dynamic register file reallocation ( also known as &# 34 ; register renaming &# 34 ;) by using the result field 31 associated with every instruction . that result field 31 is associated with the register address field 41 containing the address of the destination register for that instruction . thus , if an instruction writes to register ra , that instruction places a lock on register ra and is written in the dynamic register file 11 . if the next instruction also writes to register ra , in prior art systems that instruction cannot complete until the first instruction completes . in our system the second instruction gets another position in the dynamic register file with a destination ra ( same register ) but with a different place holder for the results . the first instruction writes the data for ra in the first place holder and the second instruction places ra data in the second place holder . the result is multiple physical instantiations of the same register . multiple instantiations are possible due to multiple entries in the dynamic register file 11 . the renaming , or removal of ambiguity , is accomplished by the fact that each place holder has a unique instruction id . the same register name rz can be associated with multiple ids located in multiple entries in the dynamic register file 11 . the register file 17 and memory are the only elements of the system that represent the state of the processor . the rest of the data in the processor , e . g ., the contents of the dynamic register file 11 and the branch shelver 13 , do not represent the state of the processor because of its temporary nature . when an incorrect branch prediction is detected , the flush inputs 69 derived from the branch shelver 13 can be applied to the dynamic register file 11 to eliminate all entries that are newer than the id of the incorrect prediction . thus , all instructions fetched and results generated after the bad prediction can be flushed from the dynamic register file 11 quickly ( in one cycle ). this action restores the processor to the state where the bad branch prediction occurred , enabling operation to resume with the fetching of instructions along the correct branch direction . the entries in the dynamic register file 11 provide a large number of instructions to be considered for possible execution , thus allowing a wide search for runnable instructions . branch prediction of multiple branches increases the number further because of the opportunity to find executable instructions within these multiple branches . this enables the processor to continue to execute instructions along branches , giving access to a larger number of instructions to increase the throughput of the processor . the condition codes are altered by instructions that compute results and set condition codes . those instructions that actually compute condition codes can also depend on other instructions that calculate some other results . in a stream of instructions , typically only a few of the instructions have a direct effect on the condition codes , and therefore , it is desirable to schedule those instructions with a higher priority than the rest of instructions , thus reducing the need for speculative processing . the performance of the processor can also be improved by calculating the condition codes sooner , which can be accomplished by having the instruction scheduler 35 issue those instructions with priority . in one implementation of our system , priority bits are stored with every instruction 27 for indicating to the instruction scheduler 33 in the dynamic register file 11 which instruction to pick up first . fig9 a and 9b together provide a more detailed diagram of the structure of the dynamic register file 11 . the dynamic register file 11 operates on the following data fields : id 29 , instruction 27 , locker1 23 , locker2 25 , rz 41 and result 31 . the instruction is broken down in a format , as illustrated in fig1 , for two source registers ( rx and ry ) 73 , 75 , a destination register ( rz ) 41 , an operation ( op - code field ) 79 , and the id 29 . the locker fields ( locker1 and locker2 ) 23 , 25 are used to hold the ids of instructions that must generate results that are required as the operands pointed to by rx and ry . the fields rz , rx , and ry are derived from the issued instruction and are part of that original instruction . when instructions enter the dynamic register file 11 , rx and ry register addresses 73 , 75 are supplied 131 to search the rz address caf 41 to make sure no younger instructions write to those registers . if no matches are found , the registers are considered unlocked and the operands are read from the register file 17 . if either rx 73 or ry 75 matches ( may - be - locked ) 127 an entry in rz 41 of an instruction that has not yet completed execution ( i . e ., result not valid ), that register is considered locked and the instruction cannot run . if one or more matches are found , then for each match , the result field 31 is read to determine if it has valid data , as indicated by a valid bit in the result register 31 . if a match is found and the result field ( where the match is found ) has valid data , the result field 31 is read as the operand in place of the register file 17 . at the same time , the id caf 29 is read . if the result field 31 does not contain valid data , the value read out of the id caf 103 will contain the youngest id of an instruction that writes to that register , i . e ., the locking instruction id . the locking id is written to the locker field 23 , 25 . the two locker fields ( locker1 23 and locker2 25 ) correspond to register address pointers rx 73 and ry 75 , respectively . thus , if a present instruction cannot run because one or both of its operands have not been generated by older instructions , then that instruction would not run , but the ids of those older instructions ( that have to generate results for the present instruction to go into execution ) are stored in locker1 23 and locker2 25 , as previously discussed . when an instruction is locked , the id of the instruction that locked the register is fed to the locker field 23 , 25 as a locker id for that register . search ports 85 in the locker cap 23 , 25 sense the update busses ( 151 in fig2 and 85 in fig9 b ) for ids which unlock instructions in the dynamic register file 11 . the instruction scheduler 33 senses instructions that are no longer locked and schedules them for execution . the result of execution of an instruction is placed onto the update bus ( 151 in fig2 and 106 , 108 in fig9 a ). the issue id caf 29 is searched 91 to find where the result should be placed in the dynamic register file 11 . the issue id content addressable first in -- first out memory caf 29 is used to hold ids of instructions as they are issued . the issue id caf is used to find the entry position in the dynamic register file 11 result field 31 where data should be written , as well as from where it should be read . there are first - in write ports for writing ids of instructions , and there are 6 search ports 91 , 93 into the issue id caf . two of these ports 91 allow data coming back on the update bus 106 , 108 from the alus 45 , 47 to be placed where the updated data should be written . the other four ports 93 are used for finding where operands are within the dynamic register file 11 . there are also two read ports 95 which allow the read out of the id of an instruction that locks a register . there are two write ports 141 which write the ids of the instructions issued into the issue id caf . it is the issue id caf 29 which maintains the order of instructions within the processor . the six search port inputs 91 , 93 to the issue id caf 29 provide a means for locating data by its id if it is within the result field 31 . two of the ports 91 are used by the update busses 151 to locate where within the result field 31 data should be stored . the match outputs of these ports become write enables 97 into the result field 31 . the other four ports 93 are supplied by the instruction scheduler 33 to locate where within the result field 31 data needed to execute an instruction or address calculation is located . the match outputs of these ports are supplied as read enables 99 into the result field 31 . the two read ports 95 are used to read out the youngest ids of instructions that have locked registers used by rx 73 and ry 75 of the issued instruction . there are also control bits from the sane state controller 19 which direct the issue id caf 29 to pop off or delete either one , two or three entries from the bottom of the fifo . there is one age output 101 per position in the id caf . the age comparator 153 is used to flush younger ids when correcting branch errors . there are also two read port outputs 103 in the issue id caf 29 that supply read outs of the youngest ids of instructions that have locked registers in the current issued instructions . each id location in the id field 29 includes eight bits that are designated as the valid bit ( 1 ), the color bit ( 1 ), and the id ( 6 ). the result field 31 maintains result slots for instructions which may or may not have finished execution . these result slots represent multiple copies of any given register or addresses for memory operations . if data is valid in the result field 31 , it may be used by other instructions for their execution , or , if the data is not valid , that register is considered locked and any instruction dependent on it must be shelved . the data in the result field 31 is used to update the register file 17 or to update memory with store operations as when that instruction becomes oldest . the result field 31 has write ports 106 , 108 that are connected to the two update bus 151 , and , when a match from the id caf is detected , data on the update bus 151 is written into the result field 31 . there are four read ports 121 to the result field 31 . two of the ports are used by the instruction scheduler 33 for getting operands for alu 45 ( if the operands are not in the rf ), and two of the ports are used in supplying operands to alu 47 for execution . the instruction issued searches the rz address caf 41 for a match . if a match is detected , the logic then determines if there is valid data in the result field 31 . if there is valid data , the register is unlocked and can be read out of the dynamic register file 11 . if there is not valid data in the result field , the register is locked and a locker id 103 is supplied by the id caf 29 . if the issued instructions are locked , the instruction scheduler 33 uses the two or the four read ports 121 for instructions that are going to the alu 45 , 47 . it supplies an id ( which searches the id caf 29 ), points to a location in the result field 31 , and also supplies the operands needed for a calculation . there are three fifo outputs 114 on the result field 31 . this allows up to the three oldest instructions to update the result field at one time . there are four random read data flow out ports 145 , 147 on the result field 31 . these allow operands to be pulled from the dynamic register file 11 if they are valid and sent to execution . the valid bits from the bottom three entries in the result field 31 are brought out and fed to the sane state controller 19 which responds when data is ready to the register file 17 by generating the appropriate signals . the rz address caf 41 holds the address of the register to be updated and is structured similar to the issue id caf 29 for determining whether a register is locked or not . when the addresses presented to the rz address caf 41 at issue time match any entries inside the rz caf , this means that an older instruction or instructions must have written to that register before the current instruction can use it . at this point , the data may or may not be in the dynamic register file 11 . if it is not in the dynamic register file 11 , the instruction will be marked as locked . when a match in the rz address caf 41 is not found , this means that the register is unlocked and the correct data value is in the register file 17 . there are two write ports 123 , and there are also two search ports 131 on the rz address caf 41 which are used to determine whether or not a register is locked . there are also three fifo outputs 125 on the rz address caf 41 which represent the oldest outstanding instructions in the processor that are ready to update the register file 17 . either one , two , or three addresses may be removed at a time although the oldest instructions must go first , in order of descending age . in addition , there are two outputs 127 per entry in the rz caf 41 to indicate may - be - locked . these lock bits do not necessarily mean that a register is locked . thus , if the data is found in the result field 31 and is valid , the register is unlocked . the may - be - locked bits 127 are the match outputs of the comparators 129 that are connected to the search port inputs 131 . because the dynamic register file 11 acts as a queuing structure for instructions that are not ready to execute , once an instruction becomes runnable , the data flow check logic 43 checks to determine if the resources are available to run the instruction . if all of the resources are available , the instruction is put into execution . the instruction field 27 stores the instruction and all of its associated decode bits that the instruction needs for execution . when an instruction is ready for execution , these bits are placed into the execution pipeline so that the instruction does not have to be decoded again . the locker caf registers 23 , 25 within the dynamic register file 11 hold the ids of instructions that lock registers needed by the instruction upon entry in the caf . there is one locker caf for each rx and ry source register 73 , 75 of the instruction . the search ports 85 of the cafs monitor the update bus and sense instructions to complete . as values are returned on the update bus , the locker caf 23 , 25 compares the id of the data on the update bus 151 with the id stored in such locker caf . when a match occurs , that register is no longer locked . when both lockers have found a match , the instruction becomes ready to run provided that there is an alu 45 , 47 available . after the match is detected , the correct value of that register will either be in the register file 17 or in the dynamic register file 11 . if the instruction on the update bus was one of the three oldest instructions , it would have therefore updated the register file 17 . if at the same time the operand becomes available and the correct resources are available to run the instruction , the instruction can be sent directly to execution . when instructions are shelved 707 , for each operand that is locked , the id of the youngest of the older instructions which locked the register is written into the locker field 23 , 25 of the dynamic register file 11 . the locker fields 23 , 25 contain the ids of the instructions for which that instruction must wait to execute to obtain its required operands . when one of those older instructions is executed it will generate a result 601 ( see fig6 ) which is required for the locked - shelved instruction . when this occurs for both lockers 23 , 25 , then that instruction will be ready for execution 401 ( see fig4 ). the data - flow check logic 43 ( see fig2 ) compares the ids of instructions writing results into the result field 31 to the locker ids of all shelved instructions . when the locker ids match the updating ids , those lockers are removed 602 . when both lockers of an instruction are removed , that instruction becomes ready to execute 401 . to allow the unshelving of an instruction and sending it to execution at the same time that a new instruction enters the dynamic register file 11 which is not locked and which can also proceed to execution , multiple execution units such as arithmetic logic units ( alu ) 45 , 47 and the associated multiplexers 49 , 51 , 53 and 55 , are provided . the dynamic register file 11 also has a first - out port illustrated at 39 in fig2 and at the fifo output ports 114 , 125 in fig9 a . results are moved from the fifo - output 114 , 125 ( collectively first - out port 39 of the dynamic register file 11 ) into the register file 17 . the dynamic register file 11 has the data flow in ports ( 151 in fig2 and 106 , 108 , 91 , and 85 in fig9 a and 9b ) and the data flow out ports 145 , 147 , and 149 in fig9 a and 9b ). the data flow out ports 145 , 147 , 149 are used to issue instructions and their operands to execution in a data flow manner , as illustrated in fig4 and 6 , and the data flow in ports 151 , 106 , 108 , 91 , and 85 are used to write results of those instructions back into the dynamic register file 11 . the results and the instructions that use the data flow ports might go into execution and come from execution out - of - order with respect to the sequence in which instructions were placed in the dynamic register file 11 . fig1 illustrates how condition codes are used by the branch execution logic . when an instruction is issued that sets the condition code register 22 , the register is locked and the id of the setting instruction 214 is saved into a lock id register 206 . when a conditional branch instruction is encountered in the instruction stream and the condition codes are locked , it cannot be determined whether or not to take the branch . in this case , a prediction is made as to which way the branch will go . execution continues in the predicted direction and an entry is made on a previously empty shelf 192 of the branch shelver 13 . this entry contains the following information : in making this entry , the shelf status is changed from empty to undet , meaning that the correct branch direction is undetermined . when a condition code has been evaluated , its value 210 is written into the condition code register 22 in fig1 , and the condition code register 22 is unlocked , provided that the id of the condition code update 208 matched 216 the id of the locker 206 . this means that no subsequent instruction has been issued that also sets that same condition code register . further , in each shelf in the branch shelver 13 that is undetermined , logic 193 , 195 checks the id of the condition code update 208 against the locker id 204 , 205 that was saved on the shelf . if these two ids are the same , then the logic 193 , 195 can determine the correct branch decision . if the initial prediction decision is the same as the correct decision just evaluated , the shelf status is changed to empty effectively purging the branch decision from the shelf , thus , making the shelf available for other instructions . if the correct branch decision is different from the predicted branch direction , however , then the shelf status is changed to wrong , as illustrated on 113 , 115 , 116 , 118 and 119 in fig3 . when any entry on the branch shelf has the status wrong , all instructions in the computer that are younger than the oldest wrong entry are purged , as illustrated at 119 in fig3 . also , all the shelves in the branch shelver 13 that have instructions younger than the oldest wrong entry are set to empty . then the computer resumes fetching instructions again , starting with the branch instruction that had been the oldest wrong instruction on the branch shelf . this second execution of the branch instruction will proceed in the correct direction since the condition codes are available . the branch shelf is implemented as an ordered list . the ordered list is a linear structure which maintains objects in insert - order . new objects are inserted into the top of the list in such a manner that the new object is always behind previously inserted objects . objects may be deleted from any position in the list . the insert - order precedence relation enables the determination of the relative age of objects in the list by their position in the list . an important property of this ordered list is that if x list cells are empty , than min ( x , i ) objects may be inserted where i is the number of inputs . the implementation of the ordered list structure shown in fig1 can be most easily explained by an example . consider a two - in ( i = 2 ), two - out ordered list with n elements or cells . the top element is arbitrarily numbered 0 and the bottom n - 1 . in addition , each of these cells contain a valid bit used to determine if the cell is empty or full . this valid bit is set when an object is inserted into the cell and reset when an object is read ( and deleted ) from the cell . an object within the list moves from the top towards the bottom whenever empty cells exist below the object . this structure may be constructed from a set of connected multiplexer - register pairs . the registers form the list cells and the multiplexers perform data routing . the multiplexers connect the input to register i ( i = 0 , 1 , 2 . . . , n - 1 ) to the output of register i , i - 1 , and i - 2 corresponding to hold , shift ( 1 ), and shift ( 2 ). the i - 1 input of cell 0 and the i - 2 input of cell 1 form the two list inputs . the i - 2 input of cell 0 is unused . two read ports are included which can read and delete any two objects within the ordered list . ______________________________________for cell i ( i = 0 , 1 , 2 ,. . ., n - 1 ), if cells i + 1 through n - 1 are full , hold ; else if there exists only one empty cell i + 1 through n - 1 , shift ( 1 ); else shift ( 2 ); ______________________________________ the effect of the logic above is that upon removal of an object from any position in the list , the list is &# 34 ; collapsed &# 34 ; downward providing empty cells on the top of the list immediately available for insertion of new objects . the logic therefore , satisfies the min ( i , x ) relation described above . only i ( i = the number of inputs ) cells must be collapsed at one time to allow i inputs even if more than i cells are empty . the shift ( 1 ) and shift ( 2 ) functions perform the collapsing . the branch shelver is a special version of the above implementation . the difference is that the read ports described above , which can read and delete any two objects from the list , are replaced by a mechanism which can delete any number of objects from the list and read any number of objects from the list . the logic which controls the movement of objects within the list is exactly the same . another unique feature of the processor of our invention is its capability for sorting instructions by type for assignment to selected ones of multiple arithmetic logic units . fig1 is a diagram illustrating this feature of our system . of the potential instructions in the dynamic register file possibly ready for execution , there may be several different arithmetic logic units to which any instruction may be sent . the object of the logic shown in fig1 is to pick the three oldest instructions and send them to the available alus . because not each alu can perform all computations , the instructions must be sorted and assigned to the proper alu . in fig1 , alu 1 300 and alu 2 305 perform all non - memory instructions , while alu 3 310 performs only memory instructions . by memory only instructions , we refer to instructions in which addresses for information and memory are computed , as well as some special move operations allowing data transfer among chips in the system . while the three alus in fig1 perform integer operations , the same architecture could be employed with floating point alus . memory 315 contains type information . the type information comes from a predecoding of the instruction and relies upon a bit in the instruction . the output from the type memory 315 is supplied to logic 320 and 325 , which in conjunction with the ready bit allow logic 330 to pick the oldest instruction ready for execution which requires the memory only alu 310 . the other path from type memory 315 allows picking the oldest and second - oldest non - memory instructions and supplying them to alu 300 and alu 305 . fig1 illustrates the operation of the flushing mechanism for flushing instructions from the dynamic register file . instructions must be flushed from the dynamic register file when they have been placed there on speculation , for example , based upon a branch prediction , and the prediction is later determined to be incorrect . in this circumstance , one wishes to flush the instructions from the dynamic register file between the designated instruction and the youngest instruction . fig1 a illustrates an example in which the youngest and oldest instructions are designated along with an instruction x which has been determined to be improperly predicted for execution . in the example depicted , the youngest instruction is not next to the oldest instruction because the register is not full of instructions , only partially full . in the example , it is desired to flush all of the instructions between instruction x and the youngest instruction . another example is shown in fig1 b in which the youngest instruction is adjacent to the oldest instruction , while the instructions requiring flushing are below the oldest instruction near the bottom of the register . flushing of the bad instructions in either of the examples of fig1 a and 14b may be achieved by generation of two vectors by the system . the first vector consists of id &# 39 ; s extending upward from the flush id instruction , while the second vector extends downward from the oldest id instruction . these vectors are shown at the right - hand side of fig1 a and 14b . the instructions which are to be flushed are determined by comparing the flush id with the id of the oldest instruction . if the flush identification is lower than the identification of the oldest instruction , then the region of instructions in which the two vectors overlap is flushed . this is shown in fig1 b . on the other hand , if the flush id is not less than the oldest id , as shown in fig1 a , then an &# 34 ; or &# 34 ; operation is performed in which all instructions designated by either of the vectors are flushed . thus , in fig1 a all of the instructions above the flush id and all of the instructions below the oldest instruction will be flushed . while the foregoing has been a description of a preferred embodiment of the processor architecture of our invention , it should be understood that many details of the architecture and its operation have been provided to explain the preferred embodiment . the scope of our invention is defined by the appended claims .