Abstract:
A data processor is disclosed that executes a number of microcode instruction words. Each of the microcode instruction words has a bit field reserved to indicate which, if any, event counters are to be incremented. This enables the number of executions of a particular microcode instruction word to be counted. By simply changing the microcode bits in the bit fields of the microcode instruction words, the event counter can be programmed to count any number or pattern of microcode instruction word executions. In one embodiment, there is a one-to-one correspondence between each bit in the bit field and each event counter. In another system, the bits in the bit field are decoded to provide an address that selects selected event counters.

Description:
RELATED APPLICATIONS 
     The present invention is related to commonly assigned U.S. Pat. No. 5,796,972, entitled METHOD AND APARATUS FOR PERFORMING MICROCODE PAGING DURING INSTRUCTION EXECUTION IN AN INSTRUCTION PROCESSOR, issued Aug. 18, 1998; and U.S. Pat. No. 5,577,259, entitled COOPERATIVE HARDWARE AND MICROCODE CONTROL SYSTEM FOR PIPELINED INSTRUCTION EXECUTION, issued Nov. 19, 1996, both of which are incorporated herein by reference. 
    
    
     FIELD OF THE INVENTION 
     The present invention generally relates to general-purpose digital data processing systems, and more particularly relates to such systems that employ memories for storing microcode in an instruction processor. The present invention includes devices and methods for measuring performance of microcoded computer systems. 
     BACKGROUND OF THE INVENTION 
     The integration of modern computer systems has been facilitated by the rapid increase in density of modem integrated circuits and printed circuit boards. The integration of computer systems has a number of advantages, including increased performance, lower power, more reliability, and a reduced cost. 
     A difficulty with increased integration is that hardware changes may be difficult and/or expensive to correct, particularly during the design cycle of a computer system. Hardware errors may be found, including logic errors, timing errors or any other type of error that reduces the effectiveness of the computer system. These errors are typically found during design verification, but may be found much later, and even after the computer system is shipped to customers. 
     In the past, mechanical methods were used to make hardware corrections. These mechanical methods include providing jumper wires, re-fabricating a printed circuit board, interchanging an integrated circuit, etc. However, with the increased integration of computer systems, mechanical methods of correcting hardware errors are often not practical (i.e. expensive) or even not possible. A primary source of this difficulty is that the internal hardware is simply not accessible. For example, to correct a hardware error in an ASIC (Application Specific Integrated Circuit) within the design, it may be necessary to create a new set of masks, and re-fabricate the integrated circuit before further verification can continue. This not only can be expensive, but can have a long turn-around time. Likewise, and because many of today&#39;s printed circuit board are multi-layered, it may not always be possible to access a trace to correct a hardware error. Thus, is may be necessary to re-fabricate the printed circuit board before further verification can continue. This may also be relatively expensive and can have a long turn-around time. 
     For these and other reasons, most modern computer systems use micro-code to control the major data paths and control points within a computer system. This may allow a system designer to provide a work around for many of the errors that are detected by simply modifying the microcode. Thus, many of the hardware errors may be corrected, at least for further verification purposes, by changing the microcode. This may allow the verification process to continue, and the system designer may continue to identify other hardware errors in the design, if any. 
     After the verification process is completed, the system designer may correct the known hardware errors in a single pass. This may significantly reduce the design cycle time of modern day computer systems. In addition, in many cases only a few functions may be affected by a hardware error, and the work around microcode corrections may be sufficient until the next design revision of the computer system is released. 
     To implement the microcode control, typical computer systems include an instruction processor that may have an instruction cache, a decoder block, and a microcode RAM. Typically, an instruction is read from the instruction cache, and is decoded by the decoder. The decoder then provides a decoded address to the microcode RAM. A microcode instruction may include one microcode instruction word or be an extended instruction having several main code instruction words executed sequentially. The microcode RAM then provides a corresponding microcode instruction to the data processing system, including a number of control signals for controlling the major data paths and control points therein. External control signals are provided to the address decoding hardware to aid in selecting which microcode instruction should be executed. For example, different microcode instruction words may be executed based on the contents of cache, attempted security violations, and register flag values. The exact route taken through the microcode may vary depending upon external conditions and may vary from execution to execution for the exact same piece of machine code. It may never be known how often certain microcode instruction words are ever executed, or even if they are ever executed. It may be desirable to improve execution of certain microcode sequences by replacing or augmenting the microcode execution with dedicated hardware or specialized circuitry. By measuring the relative frequency of use of various microcode instructions, it may be possible to determine bottlenecks in execution that are likely candidates for hardware acceleration. 
     What would be desirable, therefore, is a system for counting the number of times selected microcode instructions and instruction words are executed, if they are executed at all. What would also be advantageous is a device for determining the relative number of times each of several microcode branches are taken for a complex instruction execution. What would also be desirable is a method for selecting certain microcode instructions and measuring the frequency that the selected instructions are executed, to determine if optimizing or accelerating execution of these instructions is warranted. 
     SUMMARY OF THE INVENTION 
     The present invention is preferably used in computer systems having machine code instruction executed through microcode. An illustrative system suitable for use with the present invention includes a machine code register for holding a machine code instruction coupled to a second machine code register for extracting or stripping out the data needed to identify the associated microcode. In one embodiment, the machine code operator portion is extracted along with any needed operand type information to further distinguish the type of operator. The operator data is used as an address into an ID translation table typically implemented in RAM. The ID translation table serves to provide an address into a microcode instruction word table, which stores the actual starting microcode instruction word to be executed. The address into the microcode instruction word table can be passed first to an address generator which can either pass the microcode instruction address through or provide an alternate address, discussed below. Given the address into the microcode instruction word table, one microcode instruction word can be extracted into a microcode instruction word register, which in turn can be feed into a microcode controller for generating the multiplicity of control signals required to execute the instruction. 
     The present invention preferably includes the use of a bit field in the microcode instruction word and microcode instruction word register, which can have a length sufficient for the purpose of the present invention. The bit field includes an event counter selection field for selecting which, if any, event counter is to be incremented when a corresponding bit is set. The invention includes one or more event counters to count the execution of microcode instruction words having the proper bit set. 
     In one illustrative system, one bit is used to designate one event counter, such that the number of event counters can be equal to the number of bits in the event counter bit field, and such that more than one bit can be set and counted in different event counters in the same execution. In another system, the number of event counter selection bits is less than the number of event counters, with the bit field being used to encode the number or address of the event counter to be incremented. For example, the bit field may be interpreted as a base two number used to calculate the address of the event counter. Similarly, the event counter bit field may be three bits long and is read by a 3-to-8 decoder to select one of seven event counters to increment, with a zero value meaning no event counters are to be incremented. To add flexibility to the system, the maintenance processor may be connected to the microcode word instruction RAM for downloading modified microcode instruction words, having different bits set in the bit field allowing different microcode instruction words to be counted. 
     In use, an existing production instruction processor board or boards can be replaced with specialized instruction processor board or boards including the present invention. The specialized board can include a longer microcode instruction word length in both the microcode RAM table and in the microcode instruction register. As indicated above, the microcode instruction words may be downloaded through the maintenance processor into the microcode instruction RAM. Event counter bits are preferably set in those microcode instruction words for which counting is desired. Microcode instructions can be grouped together and given identical event counter bit field values for some applications. With the microcode instruction words loaded into RAM, computer programs can be run to force the microcode to execute. Maintenance hardware can then be used to copy the values of all event counters into a set of event counter save registers in the same single clock pulse, as a snapshot of system performance. This can allow for accurate comparison between the event counter values. The values of the event counters stored in the save registers can be read out serially, over several clock pulses and analyzed. 
     Accordingly, the present invention can be used in analyzing the number of executions of microcode instruction words where the number or occurrence of even one execution of certain microcode instruction words cannot be determined a priori from examination of machine code source alone. In one example, machine code leads to an initial location in the microcode RAM table which can be branched, depending on the values of external control signals which cannot be known at compile time or load time of the program. Examples of external signals include the presence of an operand in cache or even in memory, the value of arithmetic flags set by a previous operation, the value of security and privilege flags depending on the user and the state of the machine, etc. The branches that are actually taken through the microcode can be counted by inserting event counter bits in the event counter fields of various microcode instruction words and counting how often, if ever, certain microcode instruction words are executed. In another example, some microcode instructions are extended instructions in which one instruction word contains the address of the next microcode instruction word, where the next address can be conditionally chained, depending on the value of the external signals. 
     The present invention can thus be used to determine the relative frequency of microcode instruction word execution. Instructions that are frequently executed may be selected for optimization or hardware acceleration. Further, specialized instructions that are found to rarely or never be executed during days of testing under conditions at a user site may be removed and/or the support hardware supporting these instructions may be removed from subsequent systems. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a schematic diagram of a fully populated data processing system incorporating the present invention; 
     FIG. 2 is a pictorial diagram showing the packaging arrangement of the data processing system of FIG. 1; 
     FIG. 3 is a schematic diagram of the levels of storage for a single instruction processor; 
     FIG. 4 is a simplified block diagram showing the major elements of the instruction processor; 
     FIG. 5 is a detailed block diagram of the instruction processor; 
     FIG. 6 is a block diagram showing a second illustrative instruction processor for executing instructions, wherein the instruction processor includes a microcode RAM; 
     FIG. 7A is a block diagram showing a microcode event counter utilizing a single bit indicating whether execution of the microcode word should be counted; 
     FIG. 7B is a block diagram showing a microcode event counter utilizing three bits indicating which, if any, of three event counters should be incremented; 
     FIG. 7C is a block diagram showing a microcode event counter utilizing three bits encoding which one, if any, of seven event counters should be incremented; and 
     FIG. 8 is a block diagram showing an instruction processor including machine code to microcode decoding and showing the relationship to the event counter of FIG.  7 C. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     FIGS. 1-6 illustrate a data processing system which can include the present invention. FIG. 1 is an overall diagram of fully populated data processing system  10  which includes four individual processing clusters, each having its own storage controller and each having point-to-point communication with the other clusters via a storage controller-to-storage controller interface. 
     Storage controller  12  is coupled to storage controller  26  via interface  68 . Similarly, storage controller  12  is coupled to storage controller  28  via interface  70  and to storage controller  30  via interface  72 . Storage controller  26  communicates with storage controller  28  via interface  76  and to storage controller  30  via interface  74 . In similar fashion, storage controller  28  and storage controller  30  are coupled via interface  78 . 
     Storage controller  12  is fully populated with instruction processor  14 , instruction processor  16 , input/output processor  18 , input/output processor  20 , main memory module  22  and main memory module  24 . Each of instruction processors  14  and  16  (along with similar instruction processors  32 ,  34 ,  36 ,  38 ,  40 , and  42 ) has internal dedicated cache resources in the form of an instruction cache and an operand cache. These elements, along with the associated data invalidity logic, are described in more detail below. A more general description of the construction and operation of instruction processors  14  and  16  may be found in the above-referenced and commonly assigned U.S. patents which have been incorporated by reference. 
     Input/output processors  18  and  20 , along with main memory modules  22  and  24 , may be elements currently available, such as found in the Unisys Model 2200/600 series. Input/output processors  44 ,  46 ,  48 ,  50 ,  52  and  54  and main memory modules  56 ,  58 ,  60 ,  62 ,  64  and  66  may be similarly found. 
     FIG. 2 is a schematic diagram showing the packaging of a portion of data processing system  10 . A major physical element of data processing system  10  is Processing Complex Cabinet, PCC  25 . Within fully populated PCC  25  is located instruction processors  16  and  18  (i.e., IPA and IPB). In the preferred mode, each of these instruction processors is packaged on a single high density circuit board. The memory storage units  22  and  24  are coupled to storage controller  12  as explained above. 
     Network interface module (i.e., NIM)  27  provides an interface to the operator console via cable  29 . Cables  31  and  33  couple input/output units  18  and  20  (see also, FIG. 1) to storage controller  12 . Input/output units  18  and  20  are physically packaged in an Input/output Complex Cabinet (i.e., ICC) which is not shown for clarity. Other referenced elements are as previously described. 
     FIG. 3 is a flow diagram  80  showing the hierarchical arrangement of the three levels of storage within data processing system  10 . Instruction processor  14  contains an instruction cache  82  and an operand cache  84 , each storing 8k of 36-bit words. These are internal to instruction processor  14  and dedicated to the operations undertaken therein. By partitioning the internal dedicated cache resources in this manner, there is a certain concurrence of cache accesses associated with normal instruction execution. 
     Upon the request of instruction processor  14  to access a particular data element as either an instruction or operand, the directory of instruction cache  82  or operand cache  84 , respectively, is queried to determine if the required data element is present within the associated cache resource. If the data element is present and valid, the access is completed at that level. If not, access is made to storage controller  12  via interface  90  for the block of eight 36-bit words containing the desired data element. A more detailed explanation of the operation of instruction cache  82  and operand cache  84  is found below. 
     Storage controller  12  contains an intermediate level cache segment of 128k 36-bit words for each main memory module within the cluster. In the present illustration, storage controller  12  contains segment  0  cache  86 , and segment  1  cache  88 . These cache resources are shared by all users of the main memory within the cluster to include both local and remote users. Any memory request to storage controller  12  is routed to the appropriate directory of segment  0  cache  86  or segment  1  cache  88  to determine if the desired data element is present and valid. This routing is based upon the address requested, since the intermediate cache resources are partitioned in address space to correspond to the associated main memory module. 
     If present and valid, the requested data element is supplied as an eight-word block. If the requested data element is not validly present in segment  0  cache  86  or segment  1  cache  88  (depending upon the requested address), the data is requested from third level storage  92  containing main memory modules  22  and  24  via interfaces  94  and  96 , respectively. In the preferred mode, main memory modules  22  and  24  each contain 64 meg. words of storage. 
     Each data element request to storage controller  12  is made through a separate interface. For a fully populated system, this includes two instruction processors, two input/output processors, and three other storage controllers (see also, FIG.  1 ). Each data element request is divided between segment  0  cache  86  and segment  1  cache  88  based upon requested address. Only if the requested data element is not validly present in the appropriate intermediate level cache resource is an access request made to third level  92 . 
     FIG. 4 is a simplified block diagram of instruction processor  14  showing the major data and control paths. Cable  90 , providing the data transfer path between storage controller  12  and instruction processor  14 , is actually a two-way path. Data is accessed by storage controller  12  and routed to either instruction cache  82  or operand cache  84  depending upon whether the initial request was for instruction data or operand data. In accordance with usual local cache operation, instruction cache  82  and operand cache  84  temporarily store the data for use by instruction processor  14 . Cable  90  also couples write data from write stack  115  to storage controller  12  for longer term storage. Priority for this shared interface is ordinarily given to read data requests requiring write data to be queued in write stack  115 . The exception to giving priority to read data is whenever data is to be read from a location for which a write access has been queued. 
     Instructions from instruction cache  82  are provided via path  106  to control section  104  for decoding via microcode controller and hardwired control logic. Arithmetic execution logic  102  receives operand data via path  108  and performs the specified operation using a combination of microcode control and hardwired control as explained in greater detail below. 
     Most arithmetic instructions operate upon data which is temporarily stored in general register stack  100 . This permits most rapid access to the data, because that data is directly accessed from an extremely fast storage stack. Similarly, arithmetic results are often returned to general register stack  100  for temporary storage until further arithmetic processing. Data is routed to general register stack  100  by path  110 . Data from general register stack  100  is routed back to arithmetic execution logic  102  via path  112  and to write stack  115  via path  114 . The data transferred to write stack  115  is queued for storage by storage controller  12  as discussed above. 
     FIG. 5 is a more detailed block diagram of instruction processor  14 . The major data paths are shown, with the solid line paths signifying 72-bit, double-word transfer paths; the dashed line paths signifying addressing paths; and the dotted lines indicating data paths of no greater the 36 bits. Control line paths are not shown for clarity. 
     The interface to storage controller  12  is via cable  90 , as described above. It consists of write cable  116  and read/write cable  118 . Each of these data paths couples a 72-bit double word in parallel fashion. The function of write stack  115  (see also FIG. 4) is incorporated within store interface  120 , which also provides the request/acknowledge synchronization logic. Addressing information for store interface  120  is sent from instruction cache  82  via cable  148  and operand cache  84  via cable  150  for a corresponding cache miss. Instructions are sent to instruction cache  82  via path  146 . Because instructions are 36-bit words, path  146  has a width of 36 bits. Operand data read by storage controller  12  is transferred from store interface  120  to operand cache  84  by path  152 . Similarly, write operand data is sent from operand cache  84  to store interface  120  via path  154 . Both path  152  and path  154  have a width of 72 bits to accommodate double word operands. 
     Instructions to be executed are addressed by instruction read  124 . The addresses are computed using one of the base registers located within address environment  130 . If the instruction is the next sequential instruction, its address is determined by incrementing the program address counter. If the instruction to be executed is addressed by a branch or jump instruction, the address may be computed by address generator  126  and supplied via path  160 . Alternatively, the address may be supplied by jump prediction  122  via path  140  during operation in the jump prediction mode as explained in detail below. The address of the next instruction is provided to instruction cache  82  via path  142 . 
     The next addressed instruction is fetched from instruction cache  82  if a match is found. If the request results in a cache miss, storage controller  12  is requested to read the memory block containing the instruction as discussed above. In either case, the instruction is provided to instruction decoder  123  via path  144 . The instruction is decoded through the use of a microcode controller by instruction decode  123 , and the operand address is computed by address generator  126  from the data received via path  131 . 
     Operand cache  84  contains general register stack  100  (see also, FIG.  4 ). The cache is addressed by the output of address generator  126  received from path  158 . Direct operands are received on path  156 . If a match is not made in operand cache  84 , a read request is made of storage controller  12  through store interface  120 , as explained above. If a match is found in operand cache  84 , or if the instruction specifies a direct operand received on path  156 , the operand data is more immediately produced. In either case, the operand data is routed in accordance with the operation to be performed as specified by the instruction. Indirect operands cause the new operand address to be transferred to address generator  126  via path  168 . Operands are transferred to binary arithmetic  132  for mathematical computation via path  108  or to address environment  130  via path  166 . 
     Binary arithmetic  132  provides the basic control for all arithmetic operations to be performed on data received via path  108 . Floating point operations are scaled and controlled by floating point logic  136  which receives operand data on path  174 . Floating point results are returned to binary arithmetic  132  by path  184 . Mult./div.  134  performs the basic multiplication and division operations for fixed point instructions. Operand data is received via path  180  and the products/quotients returned via path  182  and floating point logic  136 . Decimal arithmetic  138  receives operand data on path  176  and returns results via path  178 . Decimal arithmetic performs special purpose decimal operations. 
     Another category of instructions involves a change to the base registers within the addressing environment  130 . The data is supplied to addressing environment  130  via path  166 . Base register contents are supplied to interrupt control  128  via paths  127  and  129 . Interrupt control  128  provides the interrupt data to operand cache  84  via path  170 . Control section  104  provides the overall microcode control. The operation of instruction processor  14  is intended to occur in the pipelined mode whenever feasible. The preferred modes utilizes a three-stage pipeline. 
     FIG. 6 is a block diagram showing a second illustrative instruction processor  250  for executing instructions. The instruction processor  250  includes a machine instruction memory  252 , an instruction decode block  254 , and a control block  264 . A support or maintenance processor  268  may be coupled to the processor  250  via, for example, NIM  27  of FIG.  2 . The instruction decode block  254  is similar to instruction decode block  123  of FIG. 5, and includes a microcode RAM  256  as shown. The instruction memory  252  provides machine instructions to the instruction decode block  254  during instruction execution. In one embodiment, the machine instructions are Unisys  2200  machine instructions. The instruction decode block  254  then decodes each instruction, and provides a decoded instruction address to the microcode RAM  256 . The microcode RAM  256  may store the current release of the microcode for the computer system. The microcode RAM  256  reads the corresponding address locations, and provides a corresponding microcode instruction. 
     The instruction decode block  254  provides the microcode instruction read from the microcode RAM  256  to the control block  264 . Control block  264  may then provide control signals  265  to control the major data paths and control points throughout the data processing system. 
     Referring now to FIGS. 7A,  7 B, and  7 C, a simple block diagram of one aspect of the invention is illustrated, in particular, the bit representations and hardware for counting the execution of a single microcode instruction or class of instructions is illustrated. In FIG. 7A, a microcode instruction register  302  is illustrated, having a bit field  304  with only one bit. The bit field  304  is used to indicate that a counter is to be incremented when a microcode instruction having this bit set is found in microcode instruction register  302 . The value of bit field  304  is transferred via path  306  to a counter or event counter  308  which can increment given the presence of a non-zero bit value in the bit field and the presence of a clock signal from clock signal source  310 . In a preferred embodiment, a “1” value signifies that the associated counter is to be incremented and a “0” value signifies that the counter is not to be incremented. The embodiment of FIG. 7A can be used where even one bit is unused in the microcode word and a counter and the associated connecting hardware is provided. 
     In use, when the counting of a particular microcode instruction is desired, specialized microcode can be loaded into the microcode RAM, with selected bit or bits set in the corresponding bit fields. The specialized microcode instructions are not normally loaded on the fly during normal execution, but rather loaded after a shutdown of normal processing. In a preferred embodiment, only the microcode instruction words are changed, but not the address of the microcode instruction words within the microcode RAM. For example, the same microcode address is used as before, and a similar long microcode instruction word is retrieved from RAM, but having one or more bits set that were not previously set and were not likely even present, as the microcode instruction word can be longer than before. In one method, several microcode instruction words are identically marked with the same identifier, such that the execution of all of these microcode instruction words are counted. This can be used to identify and count the execution of a group of similarly tagged microcode instructions. This can be useful where the grouping of microcode instructions are not readily apparent from an extended instruction set or other logical layout. 
     The contents of counter  308  are not immediately readable in most embodiments, but rather are read out at an appropriate time through an output path  312 . In a preferred embodiment, path  312  is implemented as a parallel readout path capable of reading out the contents of counter  308  in a single clock cycle. The readout may or may not be destructive, clearing out the register contents after the read. Reading the contents of the event counter and any other event counter in a single clock cycle allows a snapshot of the event counter values to be taken for comparison and analysis. Path  312  can transfer the contents of the event counter into an event read out register  311  which can, for example, be implemented as a shift register which can be serially read by the maintenance processor  268  via path  313 . It is comtemplated that the event counter  308  can be cleared, such as by the support processor, without effecting the operation of the system. This allows the event counter  308  to sample various job mixes or user activity at various times of the day. The examples of FIGS. 7B and 7C also may have parallel and serial read outs, which are not illustrated to simplify the drawings. 
     FIG. 7B illustrates an event counter embodiment  320  having a microcode register  322  with a bit field  324  including a first bit  326 , a second bit  328 , and a third bit  330 . First bit  326  is connected via path  327  to a counter  332 , which is read via path  333 . Second bit  328  is connected via path  329  to a counter  334 , which is read via path  335 . Third bit  330  is connected via path  331  to a counter  336 , which is read via path  337 . In event counter  320 , three counters are addressable through the three bits dedicated in the microinstruction bit field. In this embodiment, bits can be set in parallel in more than one bit position. For example, the first bit may be set for all occurrences of an extended instruction having several sub-instructions possible. Bit two may set for only one sub-instruction, and bit three set only for another sub-instruction, allowing a count of both the total number of occurrences of the extended microinstruction and the number of that total that fall within certain subsets of the microinstruction. As indicated above, the event counters may be read as discussed above with respect to FIG.  7 A. 
     FIG. 7C illustrates an event counter embodiment  360  having a 3-to-8 decoder  361 , an encoded bit field  364 , including a first bit  366  connected via a path  367  to decoder  361 , a second bit  368  connected via a path  369  to decoder  361 , and a third bit  370  connected via path  371  to decoder  361 . Decoder  361  receives the three bits of bit field  364  and provides an address of the counter to be incremented. The value “000” can signify that no counter is to be incremented, and any bits being set can be used to address counters numbers  1  through  7  or  0  through  6  depending on the numbering conventions. FIG. 7C illustrates only counters number  1 ,  2  and  7  for clarity. Once the address of a counter has been determined, one of paths  374  can be used to increment first counter  376 , second counter  378 , up to a seventh counter  380 . While three bits have been illustrated in FIG. 7C, any number of bits can be used to encode the counter address to be incremented. As indicated above, the event counters may be read as discussed above with respect to FIG.  7 A. 
     FIG. 8 illustrates a instruction decoder and microcode event counter system  400  for decoding a machine code instruction to a microcode instruction, and further counting the execution of selected microcode instructions. System  400  includes a machine code instruction cache register  402  coupled via path  403  to an FJA register  404  coupled in turn to a FJA decoder  406 . The FJA register accepts only a portion of the machine code instruction, including the portion having the addressing information needed to locate the proper microcode. For example, some of the machine instruction may refer to direct operands and not effect the microcode address selection. The FJA decoder can decode the contents of the FJA register and generate an address into an ID TRANSLATION RAM  410  which generally has a single start address for a unique opcode or opcode/operand combination in the machine code instruction. The address generated from ID XLT RAM  410  passes to microcode address generator  412  via path  411  which, in a preferred embodiment, includes internal logic and an address/control line  413  as input to the address generator  412 . The address/control line can serve to augment the input of the ID XLT RAM output such that taken together, the ID XLT RAM  410  and the address/control line  413  can generate the address into a microcode RAM table  414 . The function of the address/control line  413  is further discussed below. Address generator  412  and microcode RAM  414  serve a function similar to instruction decode block  254  in FIG.  6 . 
     Microcode RAM table  414  preferably is connected to a maintenance processor  418  via path  417 . The maintenance equipment can be used to load specialized microcode into microcode RAM table  414 . The specialized microcode instructions loaded into the microcode RAM can have a longer length than the normal microcode words, at least in part to handle extra encoding for the events counter addressing as discussed above. 
     A selected microcode instruction word is provided to a microcode controller  420  via path  419 , which can include microcode register  362  discussed above with respect to FIG.  7 C. Microcode controller  420  can generate a multiplicity of control signals to execute the function of the microcode. Microcode controller  420  receives external control signals  424  through a path  423 . External control signals  424  can include information about the state of the processor, the state of the machine, the privileges of the user, etc. The external control signals may also be derived at least in part from the history of the processor. Examples of external signals that could be included as inputs to microcode controller  420  include register flags, security address limit violations, and indicators as to whether an operand is in cache or memory. Microcode controller  420  outputs address/control signals  413  to microcode address generator  412  for use in selecting the next microcode instruction. 
     External signals  424  are one example of why the execution path of the microcode can not be predetermined purely from the machine instruction sequence. For example, while the start address of the microcode may be determined from the machine instruction, there may be further branching or other processing depending on the type of operand, the location of the operand, or the state of arithmetic status flags set by the previous operation. Thus, the sequence of branches may not be known unless some sort of tracking is provided. For example, certain microcode instructions may be extended instructions, with one word of the instruction giving the address of the next microcode instruction to be executed, and whether the microcode instruction is to be chained or extended. While some microcode instructions are always multi-word instructions, others are conditionally multi-word, depending on the external signals  424 . Thus there are some microcode instruction words that may be frequently executed or never executed, with the result being of possible interest to designers considering removing bottlenecks to performance and/or not improving those aspects of the machine which are rarely or never used. 
     An event counter address line  373  is shown extending from microcode controller  420  and being read by event counter address decoder or demultiplexer  361 , further discussed above with respect to FIG.  7 C. The remainder of the event counting hardware is preferably similar to that discussed above with respect to FIG.  7 C. 
     Numerous advantages of the invention covered by this document have been set forth in the foregoing description. It will be understood, however, that this disclosure is, in many respects, only illustrative. Changes may be made in details, particularly in matters of shape, size, and arrangement of parts without exceeding the scope of the invention. The invention&#39;s scope is, of course, defined in the language in which the appended claims are expressed.