Abstract:
Event counter checkpointing and restoring is disclosed. In one implementation, a processor includes a first event counter to count events that occur during execution within the processor, event counter checkpoint logic, communicably coupled with the first event counter, to store, prior to a transactional execution of the processor, a value of the first event counter, a second event counter to count events prior to and during the transactional execution, wherein the second event counter is to increment without resetting after the transactional execution is aborted, event count restore logic to restore the first event counter to the stored value after the transactional execution is aborted, and tuning logic to determine, in response to aborting of the transactional execution, a number of the events that occurred during the transactional execution based on the stored value of the first event counter and a value of the second event counter.

Description:
RELATED APPLICATION 
     This application is a continuation of U.S. patent application Ser. No. 12/655,204, filed on Dec. 26, 2009, the entirety of which is incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     Embodiments of the invention relate to methods of event counting or logic devices having event counters. In particular, one or more embodiments relate to methods of event counting with checkpointing and restoring or logic devices having event counters that capable of being checkpointed and restored. 
     BACKGROUND 
     Some processors include event counters. The event counters count events that occur during execution. By way of example, the events may include instructions retired, branch instructions retired, cache references, cache misses, or bus accesses, to name just a few examples. 
       FIG. 1  is a block diagram illustrating a conventional approach  100  for counting events in a logic device. The events occur in sequence from top to bottom during execution time  102 . 
     Conventional event counts  104  of a conventional event counter are shown to the right-hand side in parenthesis. Initially, M events  106  occur and are counted during committed execution. Subsequently, N events I  08  occur and are counted during execution that is ultimately aborted and/or un-committed. Bold lines  110  demarcate the N events that occur during the execution that is ultimately aborted and/or un-committed. As shown, the event counter would count through the values (M−1), (M), (M+1), (M+2), . . . (M+N), (M+N+1). 
     The conventional event counter counts all events that occur during both committed and un-committed execution in the final event count. Notice in the illustration that the event counter counts the event immediately following the N events that occur during the execution that is ultimately aborted and/or un-committed as (M+N+1). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings: 
         FIG. 1  is a block diagram illustrating a conventional approach for counting events in a logic device. 
         FIG. 2  is a block flow diagram of an embodiment of a method of counting events in a logic device. 
         FIG. 3  is a block diagram of an embodiment of a logic device. 
         FIG. 4  is a block diagram illustrating an example embodiment of counting events during speculative execution performed in conjunction with branch prediction. 
         FIG. 5  is a block diagram illustrating an example embodiment of counting events during speculative execution performed in conjunction with execution in a transactional memory. 
         FIG. 6  is a block diagram of an embodiment of a logic device having an embodiment of a first event counter to exclude events during un-committed execution from an event count and an embodiment of a second event counter to include events counted during un-committed execution in an event count. 
         FIG. 7  is a block diagram of an embodiment of a configurable logic device. 
         FIG. 8  is a block diagram of a first example embodiment of a suitable computer system. 
         FIG. 9  is a block diagram of a second example embodiment of a suitable computer system. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. 
       FIG. 2  is a block flow diagram of an embodiment of a method  212  of counting events in a logic device. In various embodiments, the method may be performed by a general-purpose processor, a special-purpose processor (e.g., a graphics processor or a digital signal processor), a hardware accelerator, a controller, or another type of logic device. 
     At block  214 , an event count of an event counter may be stored. The event counter may count events that occur during execution within the logic device. 
     Then, the event counter may be restored to the stored event count, at block  216 . Typically, the event counter has counted additional events between the time the event count was stored and the time the event count was restored. 
     Advantageously, the ability to store and restore the event count of the event counter may allow certain events to be excluded from the final event count. In one or more embodiments, events during aborted and/or un-committed execution, which is not committed to final program flow, may be excluded. For example, in one or more embodiments, events during aborted and/or un-committed speculative execution may be excluded from the final event count. Alternatively, events during other types of execution may optionally be excluded from the final event count. 
       FIG. 3  is a block diagram of an embodiment of a logic device  320 . In various embodiments, the logic device may include a general-purpose processor, a special-purpose processor (e.g., a graphics processor or a digital signal processor), a hardware accelerator, a controller, or another type of logic device. In one or more embodiments, the logic device has out-of-order execution logic. 
     The logic device has an event counter  322 . The event counter may count events that occur during execution within the logic device. For example, the counter may be incremented each time an event of a specific type occurs. The event counter has an event count  324 . 
     Suitable event counters are known in the arts. The event counters are sometimes referred to in the arts as event monitoring counters, performance monitoring counters, or simply performance counters. Further information on particular examples of suitable performance monitoring counters, if desired, is available in Intel® 64 and IA-32 Architectures Software Developer&#39;s Manual, Volume 3B, System Programming Guide, Part 2, Order Number 253669-032US, September 2009. See e.g., Chapters 20 and 30, and Appendices A-B. In one or more embodiments, the event counter is a hardware counter and/or includes circuitry. 
     Event counter checkpoint logic  326  is coupled with, or otherwise in communication with, the event counter  322 . A brief explanation of the term “coupled” may be helpful. The term “coupled” is broader than the term “connected”. As used herein, the term “connected” means that two or more elements are in direct physical or electrical contact. Likewise, the term “coupled” may mean that two or more elements are in direct physical or electrical contact. However, the term “coupled” may also mean that two or more elements are not in direct physical or electrical contact, but may still cooperate, interact, or communicate with one other. For example, the event counter and the event counter checkpoint logic may be coupled with one another through one or more intervening components. 
     The event counter checkpoint logic  326  is operable to store the event count  324  of the event counter  322 . The term “checkpoint” is sometimes used to mean different things. For clarity, as used herein, the term “checkpointing,” as in the phrase check pointing an event count, is intended to mean that the event count is stored or otherwise preserved. Likewise, the “event counter checkpoint logic” is intended to mean that the logic is operable to store or otherwise preserve the event count. In other words, the term checkpointing as used herein is not intended to inherit additional meaning other than what is explicitly stated herein. 
     As shown, in one or more embodiments, the logic device may optionally have an event count storage location  328  to store an event count  330 . In one or more embodiments, the event count storage location may include one or more special-purpose registers (e.g., one or more dedicated event counter registers) located on-die with the logic device. Alternatively, in one or more embodiments, the event count storage location may not be part of the logic device. For example, the event count storage location may be part of system memory. 
     An event count restore logic  332  is coupled with, or otherwise in communication with, the event counter. Also, in the particular illustrated embodiment, the event count restore logic is coupled with, or otherwise in communication with, the optional event count storage location. 
     The event count restore logic is operable to restore the event count  324  of the event counter  322  to the stored event count  330 . In the illustration, the particular stored event count  330  is M. The illustration also shows an example of restoring the event count  324  of the event counter  322  from the value (M+N) back to the stored event count value of M. In this example, N may represent a count of events that occur in aborted and/or un-committed execution which are excluded from the final event count. 
     One area in which embodiments disclosed herein may find great utility is in the area of speculative execution. Speculative execution generally refers to the execution of code speculatively before being certain that the execution of this code should take place and/or is needed. Such speculative execution may be used to help improve performance and tends to be more useful when early execution consumes lesser resources than later execution would, and the savings are enough to compensate for the possible wasted resources if the execution was not needed. Performance tuning inside speculative regions tends to be challenging partly because it is difficult to distinguish event counts that occur during speculative regions that are not committed to final execution from events that occur during speculative regions that are committed to final execution. 
     Speculative execution is used for various different purposes and in various different ways. As one example, speculative execution is often used with branch prediction. 
       FIG. 4  is a block diagram illustrating an example embodiment  401  of counting events during speculative execution performed in conjunction with branch prediction. 
     Initially, M events  406  may be counted by an event counter prior to a conditional branch instruction (or other control flow instruction)  432 . The conditional branch instruction results in a branch in program flow. In the illustration two branches are shown. 
     When the conditional branch instruction is encountered, the logic device may not know which of the two branches is the correct branch to be taken. Instead, branch prediction may be used to predict which branch is the correct branch. Then speculative execution may be performed earlier assuming that the predicted branch is correct. If the predicted branch is later confirmed to be correct, then the speculative execution may be committed to final code flow. Otherwise, if the predicted branch is later determined to be incorrect, then the speculative execution of the incorrect branch may be aborted. All computation past the branch point may be discarded. This execution is un-committed execution that is not committed to final code flow. Execution may then be rolled back and the correct branch may be executed un-speculatively. Checkpointing may be used to record the architectural state prior to the speculative execution so that the architectural state may be rolled back to the state it was at prior to the speculative execution. Checkpointing is traditionally used for such fault tolerance, but as previously described event counters are not traditionally checkpointed. Such branch prediction and speculative execution is well known in the arts. 
     Referring again to the illustration, after encountering the branch instruction  432 , and before counting events for the initially predicted branch, in accordance with one or more embodiments, the event count (M) of the event counter may be checkpointed or stored  434 . In one or more embodiments, a conditional branch instruction, or other control flow instruction, may represent a trigger to cause the logic device to checkpoint the event counter. 
     Then, the branch  436  on the right-hand side (in this particular case), which is the initially predicted branch, may be executed speculatively. As shown, N additional events  4  may be counted by the event counter before the speculative execution is stopped (e.g., it is determined that this branch is incorrect). The speculative execution for this branch may be aborted and not committed to final code flow. As shown, the value of the event counter when the last event of this branch was counted may be (M+N). 
     After deciding to abort the initially predicted branch, and before counting events of the committed branch  440 , in accordance with one or more embodiments, the previously stored event count (M) of the event counter may be restored  438 . In one or more embodiments, a decision to abort a speculatively executed branch may represent a trigger to cause the logic device to restore the event counter to a stored event count. The stored event count (M) may then b˜ discarded. The stored event count (M) may also be discarded if alternatively the speculative execution discussed above was committed instead of aborted. Without limitation, the program counter, registers, stacks, altered memory locations, as well as other parameters traditionally checkpointed during such speculative execution, may also be restored to their checkpointed values, although the scope of the invention is not limited in this regard. 
     Execution may then resume un-speculatively with the committed branch  440  on the left-hand side (in this particular case). The committed branch is now known to be the correct branch. The execution of the committed branch is committed to final code flow. As shown, the event counter, upon counting the first event of the committed branch, may have the event count (M+1), instead of (M+N+1), which would be the case if the N events counted during the aborted speculative execution were not excluded. 
     As another example, speculative execution is often performed in conjunction with transactional memory.  FIG. 5  is a block diagram illustrating an example embodiment  501  of counting events during speculative execution performed in conjunction with execution in a transactional memory  550 . 
     Initially, M events  506  may be counted by an event counter. The count (M) may represent a positive integer. Then a determination to perform transactional memory execution may be made. 
     Transactional memory execution is known in the arts. A detailed understanding of transactional memory execution is not needed to understand the present disclosure, although a brief overview may be helpful. 
     Some logic devices may execute multiple threads concurrently. Traditionally, before a thread accesses a shared resource, it may acquire a lock of the shared resource. In situations where the shared resource is a data structure stored in memory, all threads that are attempting to access the same resource may serialize the execution of their operations in light of mutual exclusivity provided by the locking mechanism. Additionally, there tends to be high communication overhead. This may be detrimental to system performance and/or in some cases may cause program failures, e.g., due to deadlock. 
     To reduce performance loss resulting from utilization of locking mechanisms, some logic devices may use transactional memory. Transactional memory generally refers to a synchronization model that may allow multiple threads to concurrently access a shared resource without utilizing a locking mechanism. Transactional memory may provide speculative lock elision. In transactional memory execution code may be executed speculatively within a transactional memory region without the lock. Checkpointing may be used to record the architectural state prior to the speculative execution so that the architectural state may be rolled back to the state it was at prior to the speculative execution if failure or abort occurs. If the speculative execution succeeds, the performance impact of locks may be elided. If the speculative execution is aborted, such as, for example, another component or process acquires the lock, the checkpointed architectural state may be restored. The code may then be executed un-speculatively in the transactional memory region. 
     Referring again to the illustration, after determining to perform transactional memory execution, and before counting events during the transactional memory execution, in accordance with one or more embodiments, the event count (M) of the event counter may be checkpointed or stored  534 . In one or more embodiments, a determination to perform transactional memory execution may represent a trigger to cause the logic device to checkpoint the event counter. 
     Then, the execution may be performed in the transactional memory speculatively. As shown, N additional events  508  may be counted by the event counter before the speculative execution in the transactional memory is stopped or aborted. The speculative transactional memory execution may not be committed to final code flow. As shown, the value of the event counter when the last event was counted may be (M+N). 
     After deciding to abort the speculative transactional memory execution, and before counting additional events, in accordance with one or more embodiments, the previously stored event count (M) of the event counter may be restored  538 . In one or more embodiments, a decision to abort speculative transactional memory execution may represent a trigger to cause the logic device to restore the event counter to a stored event count. The stored event count (M) may then be discarded. The stored event count (M) may also be discarded if alternatively the speculative execution discussed above was committed instead of aborted. Without limitation, the program counter, registers, stacks, altered memory locations, as well as other parameters traditionally checkpointed during such speculative execution, may also be restored to their checkpointed values, although the scope of the invention is not limited in this regard. 
     Execution may then resume. un-speculatively and one or more events may be counted during committed execution  542 . As shown, the event counter, upon counting the first event, may have the event count (M+1), instead of (M+N+1), which would be the case if the N events counted during the aborted speculative transactional memory execution were not excluded. 
     Often in such speculative transactional memory execution, the number of instructions speculatively executed and aborted is not on the order of tens to hundreds of instructions, but generally tends to be larger, such as, for example, often ranging from tens to hundreds of thousands, or even millions. As a result, the events detected during the aborted and/or un-committed execution may represent a significant proportion of the total events. Advantageously, the embodiment of the event counter described, which is able to exclude events during aborted and/or un-committed execution and selectively count events during committed execution may help to improve understanding and/or performance of the logic device. 
     These aforementioned examples of speculative execution are only a few illustrative examples of ways in which speculative execution may be used. It is to be appreciated that speculative execution may also be used in other ways. 
       FIG. 6  is a block diagram of an embodiment of a logic device  620  having an embodiment of a first event counter  622  to exclude events during un-committed execution from an event count  624  and an embodiment of a second event counter  660  to include events counted during un-committed execution in an event count  662 . 
     The logic device has the first event counter  622 . The first event counter is operable to maintain a first event count  624 . As shown, in one or more embodiments, the first event count  624  may include events counted during committed execution but may exclude events during un-committed execution. Such an event count is not available from single known event counters, and is not easily otherwise determined. 
     The logic device also has an event counter checkpoint logic  626 , an optional event count storage location  628 , and an event count restore logic  632 . These components may optionally have some or all of the characteristics of the correspondingly named components of the logic device  320  of  FIG. 3 . 
     The logic device also has a second event counter  660 . In alternate embodiments, there may be three, four, ten, or more event counters. Notice that the second event counter does not have in this embodiment, or at least does not utilize in this embodiment, event counter checkpoint logic and/or event count restore logic. That is, in one or more embodiments, at least one event counter is checkpointed and restored whereas at least one other event counter is not checkpointed and restored. The second event counter is operable to maintain a second event count  662 . As shown, in one or more embodiments, the second event count  662  may include events counted during both committed execution and events counted during un-committed execution. 
     The first event count  624 , and the second event count  662 , represent different pieces of information about execution within the logic device. As previously mentioned, the first event count includes information that is not available from a single known event counter, and is not easily otherwise determined. It provides information about those events counted during committed execution while excluding events during un-committed execution. Additionally, the combination of the first and second event counts  624 ,  662  provides additional information. For example, subtracting the first event count  624  from the second event count  662  gives information about how many events were counted during un-committed or aborted execution. This may provide information about essentially wasted execution (e.g., aborted speculative execution due to mispredicted branches and/or aborted speculative execution due to aborted transactional memory execution). 
     The first and second event counts  624 ,  662  may be used in different ways. In one or more embodiments, one or more of the first and second event counts may be used to tune or adjust the performance of the logic device. For example, in one or more embodiments, one or more of the first and second event counts may be used to tune or adjust speculative execution of the logic device. Tuning or adjusting the speculative execution may include tuning or adjusting a parameter, algorithm, or strategy. The tuning or adjusting may tune or adjust how aggressive the speculative execution is. As one particular example, if the absolute difference between the first and second event counters (which provides information about events occurring during essentially wasted execution) is higher than average, higher than a threshold, higher than desired, or otherwise considered high, then speculative execution may be decreased, throttled back, turned off, or otherwise tuned or adjusted. Depending upon the implementation, this may be desired in order to reduce heat generation, conserve battery power or other limited power supply, or for other reasons. One or more of the first arid second event counts may also or alternatively be used to analyze, optimize, and/or debug code. For example, information about wasted speculative execution may help to allow better branch prediction algorithms to be developed or selected for certain types of processing. 
     In one or more embodiments, the logic device  620  may include additional logic (not shown) to use one or more of the first and second event counts  624 ,  662  in any of these various different ways. For example, in one or more embodiments, the logic device may include performance tuning logic and/or speculative execution tuning logic. 
     In one or more embodiments, an external component  664 , which is external to the logic device, may access and/or receive one or more of the first and second event counts  624 ,  662 . In one or more embodiments, the external component may include software. In one aspect, the software may include an operating system or operating system component. In another aspect, the software may include a performance tuning application. In yet another aspect, the software may include a debugger. By way of example, in one or more embodiments, the first and/or the second event counts may be stored in a register or other storage location that may be read, for example, with a machine instruction. In one or more embodiments, the first and/or the second event counts may be used to optimize or at least improve the code so that it executes better (e.g., there is less aborted code). Performance monitoring counters are often used to improve code in this way. 
     In one or more embodiments, the external component  664  may include hardware. In one aspect, the hardware may include a system (e.g., a computer system, embedded device, network appliance, router, switch, etc.). By way of example, in one or more embodiments, the first and/or the second event counts may be provided as output on a pin or other interface. 
       FIG. 7  is a block diagram of an embodiment of a configurable logic device  720 . The configurable logic device has one or more control and/or configuration registers  767 . 
     In this embodiment, at least one event counter is capable of being enabled or disabled by a user or application for checkpoint and restore. The one or more registers have an event counter checkpoint enable/disable  768  for the at least one event counter. For example, in one particular embodiment, a single bit in a register corresponding to a particular event counter may be set to a value of one (1) to enable event counter checkpointing and restoring as disclosed herein to be performed for that event counter. If desired, a plurality or each event counter may similarly have one or more corresponding bits in one or more corresponding registers to enable or disable event counter checkpointing and restoring for each corresponding event counter. In one or more embodiments, additional bits may be provided for each event counter to specify various different types of event counter checkpointing and restoring, such as, for example, if the checkpointing and restoring is to be performed for aborted speculative execution or some other form of execution to differentiate with respect to. 
     In this embodiment, at least one event counter is a programmable event counter. The one or more registers have an event select  770  for the at least one programmable event counter. For example, in one particular embodiment, a plurality of bits (e.g., eight bits or sixteen bits, or some other number of bits) may represent a code that encodes a particular type of event to count. If desired, a plurality or each event counter may similarly have a plurality of corresponding bits in one or more corresponding registers to allow event selection for each of the event counters. In one aspect, depending upon the implementation, anywhere from tens to hundreds of different types of events may be selected for counting. Alternatively, rather than programmable event counters, fixed event counters that always count the same thing may optionally be used. 
     Still other embodiments pertain to a computer system, or other electronic device having an event counter and logic and/or performing a method as disclosed herein. 
       FIG. 8  is a block diagram of a first example embodiment of a suitable computer system  801 . The computer system includes a processor  800 . The processor includes an event counter  822 , event counter checkpoint logic  826 , and event count restore logic  832 . These may be as previously described. In one or more embodiments, the processor may be an out-of-order microprocessor that supports speculative execution. In one or more embodiments, the processor may support speculative execution in transactional memory. 
     The processor is coupled to a chipset  881  via a bus (e.g., a front side bus) or other interconnect  880 . The interconnect may be used to transmit data signals between the processor and other components in the system via the chipset. 
     The chipset includes a system logic chip known as a memory controller hub (MCH)  882 . The MCH is coupled to the front side bus or other interconnect  880 . 
     A memory  886  is coupled to the MCH. In various embodiments, the memory may include a random access memory (RAM). DRAM is an example of a type of RAM used in some but not all computer systems. As shown, the memory may be used to store instructions  887  and data  888 . 
     A component interconnect  885  is also coupled with the MCH. In one or more embodiments, the component interconnect may include one or more peripheral component interconnect express (PCie) interfaces. The component interconnect may allow other components to be coupled to the rest of the system through the chipset. One example of such components is a graphics chip or other graphics device, although this is optional and not required. 
     The chipset also includes an input/output (VO) controller hub (ICH)  884 . The ICH is coupled to the MCH through hub interface bus or other interconnect  883 . In one or more embodiments, the bus or other interconnect  883  may include a Direct Media Interface (DMI). 
     A data storage  889  is coupled to the ICH. In various embodiments, the data storage may include a hard disk drive, a floppy disk drive, a CD-ROM device, a flash memory device, or the like, or a combination thereof. 
     A second component interconnect  890  is also coupled with the ICH. In one or more embodiments, the second component interconnect may include one or more peripheral component interconnect express (PCie) interfaces. The second component interconnect may allow various types of components to be coupled to the rest of the system through the chipset. 
     A serial expansion port  891  is also coupled with the ICH. In one or more embodiments, the serial expansion port may include one or more universal serial bus (USB) ports. The serial expansion port may allow various other types of input/output devices to be coupled to the rest of the system through the chipset. 
     A few illustrative examples of other components that may optionally be coupled with the ICH include, but are not limited to, an audio controller, a wireless transceiver, and a user input device (e.g., a keyboard, mouse). 
     A network controller is also coupled to the ICH. The network controller may allow the system to be coupled with a network. 
     In one or more embodiments, the computer system may execute a version of the WINDOWS™ operating system, available from Microsoft Corporation of Redmond, Wash. Alternatively, other operating systems, such as, for example, UNIX, Linux, or embedded systems, may be used. 
     This is just one particular example of a suitable computer system. For example, in one or more alternate embodiments, the processor may have multiple cores. As another example, in one or more alternate embodiments, the MCH  882  may be physically integrated on-die with the processor  800  and the processor may be directly coupled with a memory  886  through the integrated MCH. As a further example, in one or more alternate embodiments, other components may be integrated on-die with the processor, such as to provide a system-on-chip (SoC) design. As yet another example, in one or more alternate embodiments, the computer system may have multiple processors. 
       FIG. 9  is a block diagram of a second example embodiment of a suitable computer system  901 . The second example embodiment has certain similarities to the first example computer system described immediate above. For clarity, the discussion will tend to emphasize the differences without repeating all of the similarities. 
     Similar to the first example embodiment described above, the computer system includes a processor  900 , and a chipset  981  having an I/O controller hub (ICH)  984 . Also similarly to the first example embodiment, the computer system includes a first component interconnect  985  coupled with the chipset, a second component interconnect  990  coupled with the ICH, a serial expansion port  991  coupled with the ICH, a network controller  992  coupled with the ICH, and a data storage  989  coupled with the ICH. 
     In this second embodiment, the processor  900  is a multi-core processor. The multi-core processor includes processor cores  994 - 1  through  994 -M, where M may be an integer number equal to or larger than two (e.g. two, four, seven, or more). As shown, the core-1 includes a cache  995  (e.g., an L1 cache). Each of the other cores may similarly include a dedicated cache. The processor cores may be implemented on a single integrated circuit (IC) chip. 
     In one or more embodiments, at least one, or a plurality or all of the cores may have an event counter, an event counter checkpoint logic, and event count restore logic, as described elsewhere herein. Such logic may additionally, or alternatively, be included outside of a core. 
     The processor also includes at least one shared cache  996 . The shared cache may store data and/or instructions that are utilized by one or more components of the processor, such as the cores. For example, the shared cache may locally cache data stored in a memory  986  for faster access by components of the processor. In one or more embodiments, the shared cache may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof. 
     The processor cores and the shared cache are each coupled with a bus or other interconnect  997 . The bus or other interconnect may couple the cores and the shared cache and allow communication. 
     The processor also includes a memory controller hub (MCH)  982 . As shown in this example embodiment, the MCH is integrated with the processor  900 . For example, the MCH may be on-die with the processor cores. The processor is coupled with the memory  986  through the MCH. In one or more embodiments, the memory may include DRAM, although this is not required. 
     The chipset includes an input/output (I/O) hub  993 . The I/O hub is coupled with the processor through a bus (e.g., a QuickPath Interconnect (QPI)) or other interconnect  980 . The first component interconnect  985  is coupled with the 110 hub  993 . 
     This is just one particular example of a suitable system. Other system designs and configurations known in the arts for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, micro controllers, cell phones, portable media players, hand-held devices, and various other electronic devices, are also suitable. In general, a huge variety of systems or electronic devices capable of incorporating a processor and/or an execution unit as disclosed herein are generally suitable. 
     One or more embodiments include an article of manufacture that includes a tangible machine-accessible and/or machine-readable medium. The medium may include, a mechanism that provides, for example stores, information in a form that is accessible by the machine. For example, the medium may optionally include recordable mediums, such as, for example, floppy diskette, optical storage medium, optical disk, CD-ROM, magnetic disk, magneto-optical disk, read only memory (ROM), programmable ROM (PROM), erasable-and-programmable ROM (EPROM), electrically-erasable-and-programmable ROM (EEPROM), random access memory (RAM), staticRAM (SRAM), dynamic-RAM (DRAM), Flash memory, and combinations thereof. The tangible medium may include one or more solid materials to store information. The medium may store and provide instructions, which, if processed by a machine, may result in and/or cause the machine to perform one or more of the operations or methods disclosed herein. 
     In one or more embodiments, the medium may provide instructions that if processed by the machine cause or result in the machine reading an event count of an event counter that is configured to omit events counted during aborted speculative execution from the event count. In one or more embodiments, the medium may further include instructions to cause the machine to adjusting a performance parameter of the machine (for example a speculative execution parameter) based on the event count. In one or more embodiments, the medium may further include instructions to cause the machine to read a second event count corresponding to a second event counter that is configured to include events counted during the aborted speculative execution in the event count. In one or more embodiments, the medium may further include instructions to cause the machine to evaluating a difference between the second event count and the event count. In one or more embodiments, the instructions may include instructions code of an operating system. 
     Suitable machines include, but are not limited to, general-purpose processors, special-purpose processors (e.g., graphics processors, network communications processors), network devices, computer systems, personal digital assistants (PDAs), and a wide variety of other types of electronic devices. 
     Certain operations disclosed herein may be performed by hardware components (for example a circuit). The circuit or hardware may be part of a general-purpose or special-purpose processor, or logic circuit, to name just a few examples. The operations may also optionally be performed by a combination of hardware and/or firmware and/or software. 
     In the description above, for the purposes of explanation, numerous specific details have been set forth in order to provide a thorough understanding of the embodiments of the invention. It will be apparent however, to one skilled in the art, that one or more other embodiments may be practiced without some of these specific details. The particular embodiments described are not provided to limit the invention but to illustrate it. The scope of the invention is not to be determined by the specific examples provided above but only by the claims below. In other instances, well-known circuits, structures, devices, and operations have been shown in block diagram form or without detail in order to avoid obscuring the understanding of the description. 
     It will also be appreciated, by one skilled in the art, that modifications may be made to the embodiments disclosed herein, such as, for example, to the sizes, shapes, configurations, forms, functions, materials, and manner of operation, and assembly and use, of the components of the embodiments. All equivalent relationships to those illustrated in the drawings and described in the specification are encompassed within embodiments of the invention. 
     For simplicity and clarity of illustration, elements illustrated in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals or terminal portions of reference numerals have been repeated among the figures to indicate corresponding or analogous elements, which may optionally have similar characteristics. 
     Various operations and methods have been described. Some of the methods have been described in a basic form, but operations may optionally be added to and/or removed from the methods. The operations of the methods may also often optionally be performed in different order. Many modifications and adaptations may be made to the methods and are contemplated. 
     It should also be appreciated that reference throughout this specification to “one embodiment”, “an embodiment”, or “one or more embodiments”, for example, means that a particular feature may be included in the practice of the invention. Similarly, it should be appreciated that in the description various features are sometimes grouped together in a single embodiment, Figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects may lie in less than all features of a single disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of the invention.