Counter to monitor address conflicts

Abstract

Embodiments of systems, methods, and apparatus for monitoring address conflicts are described. In some embodiments, the apparatus includes: execution circuitry for executing instructions; a plurality of registers for storing data coupled to the execution circuitry; and performance monitoring circuitry for performing address conflict counting by at least determining address conflicts between executed instructions and previously executed instructions and counting instances of each conflict.

Description

[Technical Field] The technical field of the invention generally relates to computer processor architecture, and more specifically to collision detection. [Previous Technology] Conflict detection instructions enable the vectorization of loops where access to addresses cannot be determined in nearby iterations to be compile-time dependent. However, conflict detection instructions and their corresponding ordering are costly, and whether their use results in speedup or deceleration depends on how many conflicts actually occur within a vector in an equivalent iteration. [Simplified Explanation of the Diagram] This invention is illustrated by way of example rather than by way of additional diagrams, wherein similar references refer to similar elements, and wherein: Figure 1 illustrates an embodiment of a processor (core) supporting address conflict counting; Figure 2 illustrates an embodiment of a method for address conflict counting using an address conflict counter; Figure 3 illustrates an embodiment of using configuration instructions to execute instructions for configuring an address conflict counter; Figure 4 illustrates an embodiment of address comparison hardware; Figure 5 illustrates an embodiment of comparison hardware; Figure 6 illustrates an example of tracking dummy codes for stored address conflicts within a vector iteration; Figure 7 is a block diagram of a register architecture according to an embodiment of the invention; Figure 8A is a block diagram illustrating both an exemplary sequential pipeline and an exemplary register renaming, out-of-order dispatch / execution pipeline according to an embodiment of the invention; Figure 8B is a block diagram illustrating both an exemplary sequential architecture core and an exemplary register renaming, out-of-order dispatch / execution architecture core to be included in a processor according to an embodiment of the present invention; Figures 9A-B illustrate block diagrams of more specific exemplary sequential core architectures, the core of which may be one of several logical blocks in a chip (including other cores of the same type and / or different types); Figure 10 is a block diagram of a processor according to an embodiment of the present invention that may have more than one core, may have an integrated memory controller, and may have integrated graphics; Figures 11-14 are block diagrams of exemplary computer architectures; and Figure 15 is a block diagram according to an embodiment of the present invention comparing the use of a software instruction converter for converting binary instructions in a source instruction set into binary instructions in a target instruction set. [Summary of the Invention] [Summary and Implementation of the Invention] Numerous specific details are set forth in the following description of the invention. 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 been illustrated in detail so as not to obscure the understanding of the invention. In this specification, references to "an embodiment," "an example," "an exemplary embodiment," etc., may describe embodiments that include specific features, structures, or characteristics, but each embodiment may not necessarily include that specific feature, structure, or characteristic. Furthermore, such terms do not necessarily refer to the same embodiment. Moreover, when a specific feature, structure, or characteristic is described in relation to an embodiment, it should be noted that whether such a feature, structure, or characteristic is clearly described in relation to other embodiments is within the knowledge of those skilled in the art. To effectively vectorize real dependence or conflict between vector elements, conflicts are efficiently and dynamically detected and enforced. The cost in the instructions used for each vector iteration (i.e., each VLEN scalar iteration) is conflict detection instruction + (original instruction / SIMD benefit) + conflict resolution instruction, where the denominator of the intermediate term is the SIMD benefit of calculating the lack of conflict detection and enforcement. A straightforward approach is to detect if the copied indexes are experiencing brute-force scalar comparison loops. For each index, perform a quality check on the index that has an earlier index in the vector. Another method to detect this is to use SIMD instructions to perform all the necessary comparisons (e.g., the vpconflict instruction). Unfortunately, such instructions are very expensive. To ensure correctness in the presence of conflicts, one approach is to use scalar execution. For a vectorized loop in which a conflict is detected in a given vector, for all future iterations of that vector and the loop, or anywhere in between, a fallback to scalar execution for that vector is possible. Because scalar fallback has such a dramatic effect on SIMD efficiency in the presence of a large number of collisions, we can choose to use scalar execution only when enough copies are detected. This can mean that enough index elements that are not unique or that at most one of the elements in a vector jointly indexes another have sufficient copies. The following details an example of using a performance counter to track the number of address conflicts. This information can be used to help software developers limit the performance penalty of using conflict-detecting instructions and maximize performance gains from using such instructions (including using scalar instructions instead of vector execution). This counter can be implemented (or configured) in several ways depending on the microarchitecture and the type of profiling required. For example, it can be configured to count all address conflicts anywhere within a loop. Alternatively, it can be configured for specific scenarios of address conflicts. For example, a counter can be used to count conflicts between different storage addresses within the same array that occur over several iterations. Typically, n corresponds to the vector size, such as 8 iterations for a 64-bit vector or 16 iterations for a 32-bit data type when using a 512-bit vector. Figure 1 illustrates an embodiment of a processor that supports address conflict counting. In this embodiment, core 101 includes scalar and single-instruction, multiple-data (SIMD) circuits 113 and 115 for executing scalar and SIMD / vector instructions, respectively. Execution circuits 113 and 115 are coupled to memory cell 107 and register 109. Memory cell 107 accesses memory locations, such as random access memory (RAM) and non-volatile memory (such as a disk). Register 109 includes a general purpose register and a floating-point register used by scalar execution circuit 113, and a packed data register (such as a 128-bit, 256-bit, or 512-bit packed data register) used by SIMD execution circuit 115. The performance monitoring circuit 103 (sometimes called "perfmon") monitors core functions such as execution cycle, power status, etc. Embodiments of the performance monitoring circuit 103 include an address conflict counter 105 for counting instances of address conflicts between instructions within a group of instructions. For example, the address conflict counter 105 can be configured to count instances of address conflicts within a loop (including limiting the count to several iterations of the loop), count instances of a specific type, the number of instructions, instructions describing a group of markers, or any combination thereof. Typically, this counter 105 is accessible to the programmer via an application program interface (API) call to obtain its counter value. In some embodiments, the counter 105 is a register. The performance monitoring circuit 103 includes or has access to a potentially conflicting address memory 107 for storing the stored addresses of previously executed instructions. Typically, only unique addresses are stored. In some embodiments, the memory is a content addressable memory (CAM), which allows for parallel searching of items for matching. In other embodiments, the memory is an array of addresses. In other embodiments, the memory is one or more registers (such as a plurality of general-purpose registers or packaged / compressed data registers, wherein the data elements of the packaged / compressed data registers are addresses). In some embodiments, the performance monitoring circuit 103 includes a model-specific register (MSR) 111 for defining the parameters to be checked for addressing. Typically, this register is accessible via high-privilege or ring 0 applications. The performance monitoring circuit includes a comparison circuit 117 for performing a comparison between the address of the executed instruction and the storage of potentially conflicting addresses. In some embodiments, the power monitoring circuitry includes a finite state machine (FSM) 119 for tracking packets of instructions during address conflict counting. For example, the FSM tracks the number of processed instructions to the number of instructions to be compared, or the number of iterations of the desired loop for conflict counting. In some embodiments, the performance monitoring circuitry performs address conflict counting over a group of instructions described by start and stop instructions. In some embodiments, the performance monitoring circuitry performs address conflict counting over a group of instructions described by a start instruction and a value indicating the number of instructions to be evaluated after the start instruction. Figure 2 illustrates an embodiment of a method for address conflict counting using an address conflict counter. At 201, the first instruction is executed by the execution circuitry. For example, execution of any instruction that causes writing / storing to an address or multiple addresses. Depending on the instruction, execution may be accomplished by scalar or SIMD execution circuitry. At 203, the bitwise access from the first instruction is stored in the potentially conflicting address memory. For example, if the first instruction is store, the destination address is stored in the potentially conflicting address memory, such as memory 107. At point 205, subsequent instructions are executed by the execution circuitry. For example, executing the second storage. At 207, a determination is made as to whether the address of the subsequent instruction is in the potential conflict address memory. For example, has the destination address been previously used as determined by comparing the address with those addresses previously stored in the memory location? If the address used by the subsequent instruction has not been previously used, at 209, the address is stored in the potential conflict address memory, and the next subsequent instruction is evaluated. When the address used by the subsequent instruction has been previously used, at 211, the address conflict counter is incremented, and the next subsequent instruction is evaluated. Not illustrated in this exemplary embodiment but appearing in many embodiments, is the determination of when counting should stop. For example, at the end of a loop or after several iterations of a loop. There is no output for the counter, but in many usage patterns, the controller will call the counter value to be read from the file or displayed on the screen for viewing. The controller or other entities can use the read counter value to make decisions regarding vectorization, as detailed above. Different vectorization situations require different optimization decisions: 1) If it is known that there are no conflicts within any vector in a loop (8 iterations for 64-bit data or 16 iterations for 32-bit data), vectorization normally achieves better performance without using conflict detection instructions; 2) If there is an average high number of conflicts within a vector iteration (the actual threshold is microarchitectural dependency), the best approach is usually to avoid vectorization altogether (avoid using conflict resolution instructions for vectorization) and run scalar sequences instead; and 3) If the number of conflicts within a vector iteration is small (less than the microarchitectural dependency threshold), then vectorization using conflict detection instructions usually produces the best performance. Figure 3 illustrates an embodiment of using configuration instructions to execute instructions for configuring an address conflict counter. At 301, the instruction is retrieved. Depending on the embodiment, the instruction includes an opcode and one or more fields to indicate the start of the instruction loop, the end of the loop, the conflict type, the number of iterations, etc. At 303, decode the instruction. At point 305, the data associated with the field is retrieved when needed. For example, data is retrieved from a temporary register or memory. At 307, the decoding instructions are executed to configure the address conflict counter. In some embodiments, a specific model register is set to indicate the configuration within the performance monitoring circuitry. Figure 4 illustrates an embodiment of the address comparison hardware. The group 401 of previously used addresses is compared to the address 407 used for checking. For example, the address of an instruction is compared relative to a previously used address. As described above, the address used for retesting is typically stored in a storage location of the performance monitoring circuit or is accessible to the performance monitoring circuit. The comparison hardware (circuit) 403 makes comparisons. In some embodiments, the comparison is performed one at a time. In other embodiments, the comparisons are performed in parallel. The result of comparison 405 indicates when the address conflict counter should be updated. This result is fed to an address conflict register, such as address conflict counter 105 as required. In some embodiments, only the increment of the counter is fed to the counter. Figure 5 illustrates an embodiment of the comparison hardware. Hardware 503 indicates a plurality of AND gates 509. The previously used addresses (501 and 505) and the test address 507 are fed back to each AND gate. OR gate 511 receives the result of the AND operation and outputs result 513. Any "1" indicating the address from AND gate 509 that has been previously used should be incremented by the counter. Figure 6 illustrates an example of a dummy code used to track storage address conflicts within a vector iteration. The following figures detail exemplary architectures and systems used to implement the embodiments described above. In some embodiments, one or more of the hardware components and / or instructions described above are simulated or implemented as software modules, as detailed below. Exemplary temporary register architecture Figure 7 is a block diagram of a register architecture 700 according to one embodiment of the present invention. In the illustrated embodiment, there are 32 vector registers 710, each 512 bits wide, referred to as zmm0 to zmm31. The lower 256 bits of the lower 16 zmm registers are overlapped on registers ymm0~16. The lower 128 bits of the lower 16 zmm registers (the lower 128 bits of the ymm registers) are overlapped on registers xmm0~15. Scalar operations are operations performed in the zmm / ymm / xmm register at the least significant bit position, while the positions of the higher significant bits depend on whether they were left-hand before the instruction or were zeroed out. Write mask register 715 – In the illustrated embodiment, there are eight mask registers (k0 to k7), each 64 bits in size. In an alternative embodiment, write mask register 715 is 16 bits in size. As previously described, in one embodiment of the invention, vector mask register k0 cannot be used as a write mask; when the encoding of normal indicator k0 is used as a write mask, it selects a hardwired write mask of 0xFFFF, effectively disabling the write mask for that instruction. General purpose registers 725 -- In the described embodiment, there are 16 64-bit general purpose registers, which, together with the existing x86 addressing mode, are used to address memory operands. These registers are referred to by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15. Above it is a scalar floating-point stacked register file (x87 stack) 745, aliased as MMX packed integer flat register file 750. In the illustrated embodiment, the x87 stack is an 8-element stack used to perform scalar floating-point operations on 32 / 64 / 80-bit floating-point data using x87 instruction set extensions; while using the MMX register to perform operations on 64-bit packed integer data, and to hold operands for some operations performed between the MMX and XMM registers. Alternative embodiments of the present invention may use wider or narrower registers. Furthermore, alternative embodiments of the present invention may use more, fewer, or different register files and registers. Exemplary core architecture, processor, and computer architecture Processor cores can be implemented in different ways and on different processors for different purposes. For example, such core implementations may include: 1) general-purpose sequential cores intended for general-purpose computing; 2) high-performance general-purpose out-of-order cores intended for general-purpose computing; and 3) dedicated cores intended primarily for graphics and / or scientific (processing-intensive) computing. Different processor implementations may include: 1) a CPU comprising one or more general-purpose sequential cores intended for general-purpose computing and one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor comprising one or more dedicated cores intended primarily for graphics and / or scientific (processing-intensive) computing. These different processors lead to different computer system architectures, which may include: 1) a coprocessor on a separate chip from the CPU; 2) a coprocessor on a separate die within the same package as the CPU; 3) a coprocessor on the same die as the CPU (in which case, this type of coprocessor is sometimes called dedicated logic, such as integrated graphics and / or scientific (processing) logic, or a dedicated core); 4) a system-on-a-chip may include the CPU (sometimes called an application core or application processor) on the same die, the aforementioned coprocessors, and additional functionalities. An exemplary core architecture will be described next, followed by an explanation of exemplary processors and computer architectures. Exemplary core architecture Sequential and Random Core Block Diagrams Figure 8A is a block diagram illustrating exemplary sequential pipelines and exemplary register renaming and out-of-order dispatch / execution pipelines according to embodiments of the present invention. Figure 8B is a block diagram illustrating exemplary sequential architecture cores and exemplary register renaming and out-of-order dispatch / execution architecture cores to be included in a processor according to embodiments of the present invention. Solid lines in Figures 8A and 8B illustrate sequential pipelines and sequential cores, while optional dashed lines illustrate register renaming, out-of-order dispatch / execution pipelines and cores. Given a sequential pattern that is a subset of an out-of-order pattern, the out-of-order pattern will be described. In Figure 8A, the coprocessor pipeline 800 includes a fetch stage 802, a length decoding stage 804, a decoding stage 806, an allocation stage 808, a renaming stage 810, a scheduling (also known as assignment or dispatch) stage 812, a register read / memory read stage 814, an execution stage 816, a write-back / memory write stage 818, an exception handling stage 822, and a commit stage 824. Figure 8B illustrates a processor core 890, which includes a front-end unit 830 coupled to an execution engine unit 850, and both are coupled to a memory unit 870. Core 890 can be a Reduced Instruction Set Computing (RISC) core, a Complex Instruction Set Computing (CISC) core, a Very Long Instruction Word (VLIW) core, or a hybrid or alternative core type. Alternatively, core 890 can be a dedicated core, such as a networking or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, or the like. Front-end unit 830 includes a branch prediction unit 832 coupled to instruction cache unit 834, branch prediction unit 832 coupled to instruction translation lookaside buffer (TLB) 836, instruction translation lookaside buffer 836 coupled to instruction fetch unit 838, and instruction fetch unit 838 coupled to decoding unit 840. Decoding unit 840 (or decoder) can decode instructions and generate one or more micro-operations, micro-code entry points, micro-instructions, other instructions, or other control signals as outputs, which are decoded from the original instructions or otherwise reflect or derived from the original instructions. Decoding unit 840 can be implemented using various different mechanisms. Examples of suitable mechanisms include (but are not limited to) lookup tables, hardware implementation, programmable logic arrays (PLAs), read-only memory (ROMs), etc. In one embodiment, core 890 includes a microcode ROM or other media storing microcode for certain macro instructions (e.g., in decoding unit 840 or in front-end unit 830). Decoding unit 840 is coupled to rename / allocator unit 852 in execution engine unit 850. The execution engine unit 850 includes a rename / allocator unit 852, which is coupled to a retirement unit 854 and a group of one or more scheduler units 856. Scheduler units 856 represent any number of different schedulers, including reservation stations, central command windows, etc. Scheduler units 856 are coupled to physical register file units 858. Each physical register file unit 858 represents one or more physical register files, the different ones storing one or more different data types, such as scalar integers, scalar floating-point numbers, packet integers, packet floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction index for the next instruction to be executed), etc. In one embodiment, physical register units 858 include vector register units, write mask register units, and scalar register units. These registers can provide architectural vector registers, vector mask registers, and general-purpose registers. Physical register file unit 858 is superimposed on decommissioning unit 854 to illustrate various ways in which register renaming and out-of-order execution can be performed (e.g., using a reorder buffer and decommissioned register file; using a future file, a history buffer, and decommissioned register file; using register mapping and register pools, etc.). Decommissioning unit 854 and physical register file unit 858 are coupled to execution cluster 860. Execution cluster 860 includes a group of one or more execution units 862 and a group of one or more memory access units 864. Execution unit 862 can perform various operations (e.g., shift, addition, subtraction, multiplication) and on various types of data (e.g., scalar floating-point, packet integer, packet floating-point, vector integer, vector floating-point). While some embodiments may include several execution units dedicated to a specific function or a group of functions, other embodiments may include only one or more execution units whose owner performs all functions. Scheduler unit 856, physical register file unit 858, and execution cluster 860 are illustrated as a possible plurality, because some embodiments create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point pipelines, and / or each having its own scheduler unit, physical register file unit, and / or memory access pipeline for the execution cluster—and in the case of separate memory access pipelines, some embodiments in which only the execution cluster of this pipeline has memory access unit 864 are implemented). It should also be understood that when using separate pipelines, one or more of these pipelines may be out-of-order dispatch / execution and the remainder sequential. The memory access unit 864 is coupled to the memory unit 870, which includes a data TLB unit 872, which is coupled to a data cache unit 874, which is coupled to a Level 2 (L2) cache unit 876. In an exemplary embodiment, the memory access unit 864 may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 872 in the memory unit 870. The instruction cache unit 834 is further coupled to the Level 2 (L2) cache unit 876 in the memory unit 870. The L2 cache unit 876 is coupled to one or more other levels of cache and ultimately coupled to main memory. By way of example, the exemplary register renaming, out-of-order dispatch / execution core architecture can implement the pipeline 800 as follows: 1) Instruction fetch 838 performs fetch and length decoding stages 802 and 804; 2) Decoding unit 840 performs decoding stage 806; 3) Rename / allocator unit 852 performs allocation stage 808 and rename stage 810; 4) Scheduler unit 856 performs scheduling stage 812; 5) Register file unit 858 and memory unit 870 perform register read / memory read stage 814; execution cluster 860 performs execution stage 816; 6) Memory unit 878 and register file unit 858 perform write-back / memory write stage 818; 7) Various units can be included in exception handling stage 822; and 8) Decommissioning unit 854 and register file unit 858 perform commit stage 824. Core 890 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added in newer versions); the MIPS instruction set of MIPS Technology, Sunnyvale, California; the ARM instruction set of ARM Holding, Sunnyvale, California (with optional additional extensions such as NEON), including the instructions described herein. In one embodiment, core 890 includes logic for supporting packet data instruction set extensions (e.g., AVX1, AVX2), thereby allowing operations by a variety of multimedia applications to be performed using packet data. It should be understood that the core can support multithreading (execution of two or more parallel groups of operations or threads) and can do so in various ways, including time-sliced ​​multithreading, simultaneous multithreading (where a single physical core provides logical cores for each thread of simultaneous multithreading by the physical core), or a combination thereof (such as time-sliced ​​extraction and decoding and simultaneous multithreading in Intel® Hyperthreading technology). While register renaming is described in the context of out-of-order execution, it should be understood that register renaming can also be used in sequential architectures. While the described processor embodiments also include separate instruction and data cache units 834 / 874 and a shared L2 cache unit 876, alternative embodiments may have a single internal cache for both instructions and data, such as a Level 1 (L1) internal cache or multiple levels of internal caches. In some embodiments, the system may include a combination of internal caches and external caches located outside the core and / or processor. Alternatively, all caches may be external to the core and / or processor. Specific Exemplary Sequential Core Architecture Figures 9A-B illustrate block diagrams of more specific exemplary sequential core architectures, where the core is one of several logic blocks in the chip (including other cores of the same and / or different types). Depending on the application, the logic block communicates with some fixed-function logic, memory I / O interfaces, and other necessary I / O logic via a high-bandwidth interconnect network (e.g., a ring network). Figure 9A is a block diagram of a single processor core according to an embodiment of the present invention, along with its connection to the on-die interconnect 902 and a subset of regions having its Level 2 (L2) cache 904. In one embodiment, the instruction decoder 900 supports the x86 instruction set with packet data instruction set extensions. The L1 cache 906 allows low-latency access to cache memory into scalar and vector units. While in one embodiment (for design simplification), scalar units 908 and vector units 910 use separate register sets (scalar register 912 and vector register 914, respectively) and data transfers between them are written to memory and then read back to / from the Level 1 (L1) cache 906, alternative embodiments of the present invention may use different methods (e.g., using a single register set or including a communication path that allows data to be transferred between two register files without writing and reading back). The L2 cache 904 is a subset of the global L2 cache, divided into separate subsets, one for each processor core. Each processor core has a direct access path to its own subset of the L2 cache 904. Data read by a processor core is stored in its L2 cache subset 904 and can be accessed quickly, in parallel with other processors accessing their own L2 cache subsets. Data written by a processor core is stored in its own L2 cache subset 904 and flushed from other subsets if necessary. A ring network ensures consistency / coherency for shared data. The ring network is bidirectional, allowing intermediaries such as processor cores, L2 caches, and other logic blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction. Figure 9B is an expanded view of a portion of the processor core shown in Figure 9A according to an embodiment of the present invention. Figure 9B includes L1 data cache 906A, a portion of L1 cache 904, and further details regarding vector unit 910 and vector register 914. Specifically, vector unit 910 is a 16-width vector processing unit (VPU) (see 16-width ALU 928) that executes one or more of integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports swizzling register inputs using swizzling unit 920, numerical conversion using value conversion units 922A-B, and copying on memory inputs using copy unit 924. Write mask register 926 allows determination of vector writes. Figure 10 is a block diagram of a processor 1000 according to an embodiment of the present invention, which may have more than one core, an integrated memory controller, and an integrated graphics. The solid boxes in Figure 10 illustrate a processor 1000 with a single core 1002A, a system agent 1010, and a group of one or more bus controller units 1016. The optional dashed boxes illustrate alternative processors with multiple cores 1002A to N, a group of one or more integrated memory controller units 1014 in the system agent unit 1010, and dedicated logic 1008. Therefore, different implementations of processor 1000 may include: 1) a CPU with dedicated logic 1008 that is integrated graphics and / or scientific (processing) logic (which may include one or more cores), and cores 1002A~N that are one or more general-purpose cores (e.g., general-purpose sequential cores, general-purpose out-of-order cores, or a combination of both); 2) a coprocessor with cores 1002A~N that is a large number of dedicated cores primarily intended for graphics and / or scientific (processing); and 3) a coprocessor with cores 1002A~N that is a large number of general-purpose sequential cores. Thus, processor 1000 may be a general-purpose processor, coprocessor, or dedicated processor, such as a network or communication processor, compression engine, graphics processor, GPGPU (general purpose graphics processing unit), high-capacity many integrated core (MIC) coprocessor (including 30 or more cores), embedded processor, or the like. The processor may be implemented on one or more chips. The processor 1000 may be implemented on one or more substrates as part of the substrate and / or using any of several processor technologies, such as BiCMOS, CMOS or NMOS. A memory hierarchy includes one or more levels of cached memory within the core, a group of shared cache units 1006, and external memory (not shown) coupled to the group of integrated memory controller units 1014. The group of shared cache units 1006 may include one or more intermediate caches, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other levels of cache, last-level cache (LLC), and / or combinations thereof. While in one embodiment the integrated graphics logic 1008, the group of shared cache units 1006, and the system proxy unit 1010 / integrated memory controller unit 1014 are interconnected based on a ring interconnect unit 1012, alternative embodiments may use any number of well-known techniques for interconnecting such units. In one embodiment, consistency is maintained between the one or more cache units 1006 and the cores 1002-A~N. In some embodiments, one or more of the cores 1002A-N are capable of multi-threaded execution. System agent 1010 includes components that coordinate and operate the cores 1002A-N. System agent unit 1010 may, for example, include a power control unit (PCU) and a display unit. The PCU may be or include logic and components required for regulating the power states of the cores 1002A-N and the integrated graphics logic 1008. The display unit is used to drive one or more externally connected displays. Cores 1002A~N can be homogeneous or heterogeneous in terms of their instruction sets; that is, two or more of cores 1002A~N can execute the same instruction set, while the others can execute only a subset of that instruction set or a different instruction set. Exemplary computer architecture Figures 11-14 are block diagrams of exemplary computer architectures. They are also applicable to other system designs and configurations known in the art for laptops, desktop computers, 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, microcontrollers, mobile phones, portable media players, handheld devices, and various other electronic devices. Generally, it is suitable to disclose the wide variety of systems or electronic devices that can include processors and / or other execution logic herein. Referring now to FIG11, a block diagram of a system 1100 according to one embodiment of the present invention is shown. System 1100 may include one or more processors 1110, 1115 coupled to a controller hub 1120. In one embodiment, the controller hub 1120 includes a graphics memory controller hub (GMCH) 1190 and an input / output hub (IOH) 1150 (which may be on a separate chip); the GMCH 190 includes memory and a graphics controller, to which memory 1140 and a coprocessor 1145 are coupled; the IOH 1150 is the coupling of an input / output (I / O) device 1160 to the GMCH 1190. Alternatively, one or both of the memory and the graphics controller are integrated within the processor (as described herein), with memory 1140 and coprocessor 1145 directly coupled to processor 1110, and controller hub 1120 in a single chip with IOH 1150. The optional nature of the additional processor 1115 is indicated by dashed lines in Figure 11. Each processor 1110, 1115 may include one or more of the processing cores described herein and may be a version of processor 1000. Memory 1140 may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of both. In at least one embodiment, controller hub 1120 communicates with processors 1110, 1115 via a multi-drop bus, such as a frontside bus (FSB), a point-to-point interface such as QuickPath Interconnect (QPI), or a similar connection 1195. In one embodiment, the coprocessor 1145 is a dedicated processor, such as a high-throughput MIC processor, network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. In one embodiment, the controller hub 1120 may include an integrated graphics accelerator. According to the spectrum of metrics of merit, there can be various differences between entity resources 1110 and 1115, including architectural, microarchitectural, thermal, power consumption characteristics and similar aspects. In one embodiment, processor 1110 executes instructions that control general-type data processing operations. Embedded within these instructions may be coprocessor instructions. Processor 1110 recognizes these coprocessor instructions as being of the type to be executed by an attached coprocessor 1145. Accordingly, processor 1110 dispatches these coprocessor instructions (or control signals representing the coprocessor) to coprocessor 1145 on a coprocessor bus or other interconnect. Coprocessor 1145 receives and executes the received coprocessor instructions. Referring now to FIG12, a block diagram of a first more specific exemplary system 1200 according to an embodiment of the present invention is shown. As illustrated in FIG12, the multiprocessor system 1200 is a point-to-point interconnect system and includes a first processor 1270 and a second processor 1280 coupled via a point-to-point interconnect 1250. Each of processors 1270 and 1280 may be a version of processor 1000. In one embodiment of the present invention, processors 1270 and 1280 are processors 1110 and 1115, respectively, while coprocessor 1238 is coprocessor 1145. In another embodiment, processors 1270 and 1280 are processor 1110 and coprocessor 1145, respectively. Processors 1270 and 1280 are illustrated to include integrated memory controller (IMC) units 1272 and 1282, respectively. Processor 1270 also includes point-to-point (PP) interfaces 1276 and 1278 as part of its bus controller unit; similarly, the second processor 1280 includes PP interfaces 1286 and 1288. Processors 1270 and 1280 can exchange information via point-to-point (PP) interface 1250 using PP interface circuitry 1278 and 1288. As illustrated in Figure 12, IMCs 1272 and 1282 couple the processors to respective memories, namely memories 1232 and 1234, which may be portions of the main memory of the respective processors. Processors 1270 and 1280 can exchange information with chipset 1290 via point-to-point interface circuits 1276, 1294, 1286, and 1298 through individual PP interfaces 1252 and 1254. Chipset 1290 can selectively exchange information with coprocessor 1238 via high-performance interface 1239. In one embodiment, coprocessor 1238 is a dedicated processor, such as a high-throughput MIC processor, network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. A shared cache (not shown) may be included in one of the two processors or outside the two processors, or connected to the processors via a PP interconnect, such that if the processors are placed in a low-power mode, the regional cache information of one or both processors can be stored in the shared cache. Chipset 1290 may be coupled to first bus 1216 via interface 1296. In one embodiment, first bus 1216 may be a peripheral component interconnect (PCI) bus, or such as a fast PIC bus (PCI Express) or another third-generation I / O interconnect bus, although the scope of the invention is not so limited. As illustrated in Figure 12, various I / O devices 1214 may be coupled to a first bus 1216, together with a bus bridge 1218 that couples the first bus 1216 to a second bus 1220. In one embodiment, one or more additional processors 1215, such as a coprocessor, a high-throughput MIC processor, a GPGPU, an accelerator (e.g., a graphics accelerator or digital signal processing (DSP) unit), a field-programmable gate array, or any other processor, are coupled to the first bus 1216. In one embodiment, the second bus 1220 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 1220, such as a keyboard and / or mouse 1222, a communication device 1227, and a storage unit 1228, such as a disk drive or other mass storage device that may include instruction / code and data 1230. Furthermore, the audio I / O 1224 can be coupled to the second bus 1220. Note that other architectures are possible. For example, instead of the point-to-point architecture of Figure 12, the system can implement a multi-point downlink bus or other similar architectures. Referring now to FIG13, a block diagram of a first more specific exemplary system 1300 according to an embodiment of the present invention is shown. Similar elements in FIG12 and 13 are represented by similar reference numerals, and some features of FIG12 have been omitted from FIG13 to avoid obscuring other features of FIG13. Figure 13 illustrates that processors 1270 and 1280 may include integrated memory and I / O control logic ("CL") 1272 and 1282, respectively. Therefore, CL 1272 and 1282 include integrated memory controller units and I / O control logic. Figure 13 not only illustrates that memories 1232 and 1234 are coupled to CL 1272 and 1282, but also that I / O device 1314 is coupled to control logic 1272 and 1282. The legacy I / O device 1315 is coupled to chipset 1290. Referring now to FIG14, a block diagram of a SoC 1400 according to an embodiment of the present invention is shown. Similar elements in FIG10 are represented by similar reference numerals. Also, dashed boxes represent optional features on more advanced SoCs. In FIG14, interconnect unit 1402 is coupled to: an application processor 1410 including a group of one or more cores 202A~N and a shared cache unit 1006; a system proxy unit 1010; a bus controller unit 1016; an integrated memory controller unit 1014; a group of one or more coprocessors 1420 including integrated graphics logic, an image processor, an audio processor and a video processor; a static random access memory (SRAM) unit 1430; a direct memory access (DMA) unit 1432; and a display unit 1440 for coupling to one or more external displays. In one embodiment, the coprocessor 1420 includes a dedicated processor, such as a network or communications processor, a compression engine, a GPGPU, a high-throughput MIC processor, an embedded processor, or the like. Embodiments of the mechanism disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation methods. Embodiments of the invention may be implemented as computer programs or code that execute on a programmable system comprising at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. Program code, such as code 1230 illustrated in Figure 12, can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system with a processor, such as a digital signal processor (DSP), microcontroller, application-specific integrated circuit (ASIC), or microprocessor. Program code can be implemented in high-level programming or object-oriented programming languages ​​to communicate with the processing system. If desired, the code can also be implemented in composition or machine language. In fact, the mechanisms described herein are not limited to any particular programming language. In any case, the language can be compiled or interpreted. At least one or more embodiments can be implemented by representative instructions stored on a machine-readable medium, representing various logics within a processor, which, when read by a machine, cause machine-made logic to perform the techniques described herein. Such representations, known as "IP cores," can be stored on tangible, machine-readable media and supplied to various customers or manufacturing facilities for loading into manufacturing machines that actually make up the logic or processor. Such machine-readable media may include, but are not limited to: non-transitory, tangible configurations of objects made or formed by machines or devices, including storage media such as hard disks, including floppy disks, optical disks, compressed magnetic disk read-only memory (CD-ROM), rewritable optical disks (CD-RW), and any other type of magnetic disk, including semiconductor devices such as read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM), phase-change memory (PCM), magnetic or optical cards, or any other type of media suitable for storing electronic instructions. Accordingly, embodiments of the present invention also include non-transitory, tangible machine-readable media containing instructions or design data, such as a Hardware Description Language (HDL), which defines structures, circuits, devices, processors, and / or system features described herein. Such embodiments may also be referred to as program products. Simulation (including binary decoding, code morphing, etc.) In some situations, an instruction translator can be used to translate instructions from a source instruction set to a target instruction set. For example, an instruction translator can translate (e.g., using static binary translation, including dynamic binary translation with dynamic compilation), deform, emulate, or otherwise translate instructions into one or more other instructions to be processed by the kernel. Instruction translators can be implemented in software, hardware, firmware, or a combination thereof. Instruction translators can be on-processor, off-processor, or partially on-processor and partially off-processor. Figure 15 is a block diagram comparing the use of a software instruction converter for converting binary instructions in a source instruction set into binary instructions in a target instruction set, according to an embodiment of the present invention. In the illustrated embodiment, the instruction converter is a software instruction converter; alternatively, the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. The program illustrated in Figure 15 in the high-level language 1502 can be compiled using an x86 compiler 1504 to generate x86 binary code 1506, which can be natively executed by a processor 1516 having at least one x86 instruction set core. The processor 1516 having at least one x86 instruction set core represents a processor capable of substantially performing the same functions as an Intel processor having at least one x86 instruction set core by compatiblely executing or otherwise processing the following: (1) a substantial portion of the instruction set of the Intel x86 instruction set core, or (2) an object code version of an application or other aligned software, for running on an Intel processor having at least one x86 instruction set core in order to substantially achieve the same results as an Intel processor having at least one x86 instruction set core. The x86 compiler 1504 represents a compiler operable to generate x86 binary code 1506 (e.g., object code), which, with or without additional linking processing, is executed on the processor with at least one x86 instruction set core 1516. Similarly, the program illustrated in Figure 15 in the high-level language 1502 can be compiled using an alternative instruction set compiler 1508 to generate alternative instruction set binary code 1510, which can be executed natively by a processor without having at least one x86 instruction set core 1514 (e.g., a processor with a core executing the MIPS instruction set of MIPS technology from Sunnyvale, California, and / or the ARM instruction set of Arm Holdings, Sunnyvale, California). An instruction converter 1512 is used to translate the x86 binary code 1506 into a core that can be executed natively by a processor without having an x86 instruction set core 1514. This translated code is unlikely to be identical to the alternative instruction set binary code 1510, as such an instruction converter would be difficult to manufacture; however, the translated code will perform general operations and consist of instructions from the alternative instruction set. Therefore, the instruction converter 1512 represents software, firmware, hardware, or a combination thereof, although emulation, simulation, or any other process allows the processor or other electronic device that does not have an x86 instruction set processor or core to execute x86 binary code 1506.

Claims

1. An apparatus for monitoring address conflicts, comprising: a Single Instruction Multiple Data (SIMD) execution circuit for executing instructions; a plurality of registers for storing data coupled to the execution circuit; an address conflict memory for storing a unique address used by a previously executed instruction; and a performance monitoring circuit for performing address conflict counting by at least determining an address conflict between the executed instruction and the address of the previously executed instruction stored in the address conflict memory and counting instances of the conflict, wherein the executed instruction and the previously executed instruction are executed by the SIMD execution circuit, wherein the performance monitoring circuit includes: an address conflict counter for storing count values ​​of instances of conflict, wherein the count values ​​are used to make vectorization decisions, wherein different vectorization situations require different optimization decisions: 1) if it is known that there is no conflict in any vector of the loop, better performance can be obtained normally by vectorization without using a conflict detection instruction; 2) If the average number of conflicts within a vector iteration is greater than or equal to the microarchitecture dependency threshold, then do not vectorize at all and run scalar sequences instead. And 3) If the average number of conflicts within a vector iteration is less than the microarchitecture dependency threshold, then the best performance is achieved by using vectorization of conflict detection instructions.

2. The device of claim 1, wherein the performance monitoring circuit comprises: a potential conflict address memory for storing the address of a previously executed instruction; and a comparison circuit for performing a comparison between the address of the executed instruction and the address stored in the potential conflict address memory.

3. The device as claimed in claim 2, wherein the performance monitoring circuit further includes: a specific model register for configuring the performance monitoring circuit for address conflict counting.

4. The device of claim 2, wherein the performance monitoring circuit further includes: a finite state machine for tracking packets of instructions during address conflict counting.

5. The device as claimed in claim 1, wherein the unique address is a write address.

6. The device of claim 1, wherein the performance monitoring circuit is used to perform address conflict counting during a single iteration of a loop.

7. The device of claim 1, wherein the performance monitoring circuit is used to perform address conflict counting during multiple overlap cycles of a loop.

8. The device of claim 1, wherein the performance monitoring circuit is used to perform address conflict counting during the grouping of instructions described by start and stop instructions.

9. The device of claim 1, wherein the performance monitoring circuit is used to perform address conflict counting during a grouping of instructions described by a start instruction and a value indicating the number of instructions to be evaluated after the start instruction.

10. A method for monitoring address conflicts, comprising: executing a first Single Instruction Multiple Data (SIMD) instruction; storing an address used by the executed first instruction in a potential address conflict memory, the potential address conflict memory storing the address of a previously executed instruction; executing a second SIMD instruction; and, in response to the execution of the second SIMD instruction, determining that the address of the executed second instruction matches an address in the potential address conflict memory; And increment the address conflict counter; and output the value of the address conflict counter, wherein the value of the address conflict counter is used to make a decision on vectorization, wherein different vectorization situations require different optimization decisions: 1) If it is known that there is no conflict in any vector in the loop, better performance can be obtained normally by vectorization without using conflict detection instructions; 2) If the average number of conflicts within a vector iteration is greater than or equal to the microarchitecture dependency threshold, then do not vectorize at all and run scalar sequences instead. And 3) If the average number of conflicts within a vector iteration is less than the microarchitecture dependency threshold, then the best performance is achieved by using vectorization of conflict detection instructions.

11. The method of claim 10, wherein the address stored in the potential address conflict memory is unique.

12. The method of claim 11, wherein the addresses stored in the potential address conflict store are a list.

13. The method of claim 11, wherein the potential address conflict memory is a content addressable memory.

14. The method of claim 11, wherein the address is a write address.

15. The method of claim 11, wherein the method is performed in a processor performance monitoring circuit.

16. The method of claim 11, wherein the determination is made by ANDing the address of the second instruction with the addresses of the potential address conflict memory and ORing the result of the AND.

Images