Method and apparatus for processor trace trigger tracking

Abstract

Methods and apparatus for processor trace trigger tracking. A processor comprising: a plurality of processing cores configurable as a plurality of logical processors; processor trace circuitry to perform trace operations to capture and process information related to program code executed by one or more of the logical processors; a debug unit to perform a debug operation and collect debug data related to execution of the program code; a performance monitoring unit (PMU) including a plurality of counter registers, the PMU collecting performance data related to execution of the program code; and a plurality of trigger units, each trigger unit associated with a logical processor of the plurality of logical processors and configured to respond to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register, the trigger event data is communicated to a processor trace circuit.

Description

Technical Field

[0001] The present invention relates generally to the field of computer processors. More particularly, the present invention relates to methods and apparatus for processor trace trigger tracing. Background Art

[0002] The instruction set, or instruction set architecture (ISA), is the part of the computer architecture related to programming, including native data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input and output (I / O). It should be noted that the term "instruction" in this article generally refers to macroinstructions - that is, instructions provided to the processor for execution - rather than microinstructions or microoperations - which are the result of the processor's decoder decoding the macroinstructions. Microinstructions or microoperations can be configured to instruct the execution units on the processor to perform operations to implement the logic associated with the macroinstructions.

[0003] ISA is different from microarchitecture, which is the collection of processor design techniques used to implement an instruction set. Processors with different microarchitectures can share a common instruction set. For example, Intel Pentium 4 processor, Intel Core TM The processor and the processor from Advanced Micro Devices, Inc. of Sunnyvale, California implement almost the same version of the x86 instruction set (with some extensions added with newer versions), but have different internal designs. For example, the same register architecture of the ISA can be implemented in different ways in different microarchitectures using well-known techniques, including dedicated physical registers, one or more dynamically allocated physical registers using a register renaming mechanism (e.g., using a register alias table (RAT), a reorder buffer (ROB), and a retirement register file). Unless otherwise specified, the phrases "register architecture", "register file", and "register" are used herein to refer to what is visible to the software / programmer, and the way instructions specify registers. Where a distinction is required, the adjectives "logical", "architectural", or "software visible" will be used to indicate registers / files in a register architecture, while different adjectives will be used to specify registers in a given microarchitecture (e.g., physical registers, reorder buffers, retirement registers, register pools). Summary of the invention

[0004] According to one aspect of the present disclosure, a processor is provided, comprising: a plurality of processor cores configurable as a plurality of logical processors; a processor trace circuit to perform trace operations to capture and process information related to program code executed by one or more of the logical processors; a debug unit to perform debug operations and collect debug data related to the execution of the program code; a performance monitoring unit (PMU) including a plurality of counter registers, the PMU collecting performance data related to the execution of the program code; and a plurality of trigger units, each trigger unit being associated with a logical processor of the plurality of logical processors and configured to communicate trigger event data to the processor trace circuit in response to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register.

[0005] According to another aspect of the present disclosure, a method is provided, including: performing, by a processor trace circuit, a trace operation to capture and process information related to program code executed by one or more logical processors; performing, by a debug unit, a debug operation including collecting debug data related to the execution of the program code; collecting, by a performance monitoring unit (PMU) including a plurality of counter registers, performance data related to the execution of the program code; and communicating, by a trigger unit of a plurality of trigger units, trigger event data to the processor trace circuit in response to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register.

[0006] According to another aspect of the present disclosure, a machine-readable medium is provided, on which program code is stored, which, when executed by a machine, causes the machine to perform operations, the operations including: indicating a plurality of logical processors; performing, by a processor trace circuit, a trace operation to capture and process information related to program code executed by one or more of the logical processors; performing, by a debug unit, a debug operation including collecting debug data related to the execution of the program code; collecting, by a performance monitoring unit (PMU) including a plurality of counter registers, performance data related to the execution of the program code; and communicating, by a trigger unit of a plurality of trigger units, trigger event data to the processor trace circuit in response to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] A better understanding of the present invention may be obtained from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0008] Figure 1 illustrates an example computer system architecture;

[0009] Figure 2A processor including multiple cores is illustrated;

[0010] FIG3(A) illustrates the various stages of a processing pipeline;

[0011] FIG3(B) illustrates details of one embodiment of the core;

[0012] Figure 4 illustrates an execution circuit according to one embodiment;

[0013] Figure 5 One embodiment of a register architecture is illustrated;

[0014] Figure 6 An example of an instruction format is illustrated;

[0015] Figure 7 illustrates an addressing technique according to one embodiment;

[0016] Figure 8 An embodiment of an instruction prefix is ​​illustrated;

[0017] 9(A)-9(D) illustrate an embodiment of how the R, X, and B fields of the prefix may be used;

[0018] 10(A)-10(B) illustrate examples of a second instruction prefix;

[0019] Fig.11 illustrates the payload bytes of one embodiment of an instruction prefix;

[0020] Fig.12 The diagram shows how instruction conversion and binary translation are implemented;

[0021] Fig.13 An example of processor trace logic executing a processor trace instruction is illustrated;

[0022] Fig.14 illustrates an embodiment of processor trace logic for collecting trace data;

[0023] Fig.15 illustrates one embodiment of a trace unit within a processor core;

[0024] Fig.16 One embodiment of a trigger unit coupled to debug registers and performance monitoring counters is illustrated;

[0025] Fig.17 illustrates additional details associated with a trigger unit of a logic processor; and

[0026] Fig.18 A method according to one embodiment of the present invention is illustrated. DETAILED DESCRIPTION

[0027] In the following description, for illustrative purposes, many specific details are recorded in order to provide a thorough understanding of the embodiments of the present invention described below. However, it will be clear to those skilled in the art that embodiments of the present invention can be implemented without some of these specific details. In other cases, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of embodiments of the present invention.

[0028] Exemplary Computer Architecture

[0029] The exemplary computer architecture is described in detail below. Other system designs and configurations 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, cellular phones, portable media players, handheld devices, and various other electronic devices known in the art are also appropriate. In short, various systems or electronic devices that can include processors and / or other execution logic disclosed herein are generally appropriate.

[0030] Figure 1 An embodiment of an exemplary system is illustrated. Multiprocessor system 100 is a point-to-point interconnect system and includes a plurality of processors, including a first processor 170 and a second processor 180 coupled via a point-to-point interconnect 150. In some embodiments, first processor 170 and second processor 180 are homogeneous. In some embodiments, first processor 170 and second processor 180 are heterogeneous.

[0031] Processors 170 and 180 are shown as including integrated memory controller (IMC) unit circuits 172 and 182, respectively. Processor 170 also includes point-to-point (PP) interfaces 176 and 178 as part of its interconnect controller unit; similarly, second processor 180 includes PP interfaces 186 and 188. Processors 170, 180 may exchange information via point-to-point (PP) interface 150 using PP interface circuits 178, 188. IMCs 172 and 182 couple processors 170, 180 to respective memories, namely memory 132 and memory 134, which may be part of the main memory locally attached to the respective processors.

[0032] Processors 170, 180 may each utilize point-to-point interface circuits 176, 194, 186, 198 to exchange information with chipset 190 via individual PP interconnects 152, 154. Chipset 190 may optionally exchange information with coprocessor 138 via high-performance interface 192. In some embodiments, coprocessor 138 is a special-purpose processor such as, for example, a high-throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like.

[0033] A shared cache (not shown) may be included in either processor 170, 180, or external to both processors but connected to the processors via the PP interconnect, such that local cache information of either or both processors may be stored in the shared cache when the processors are placed in a low power mode.

[0034] Chipset 190 may be coupled to first interconnect 116 via interface 196. In some embodiments, first interconnect 116 may be a Peripheral Component Interconnect (PCI) interconnect, or an interconnect such as a PCI Express interconnect or another I / O interconnect. In some embodiments, one of the interconnects is coupled to a power control unit (PCU) 117, which may include circuits, software, and / or firmware to perform power management operations with respect to processors 170, 180, and / or coprocessor 138. PCU 117 provides control information to the voltage regulator to cause the voltage regulator to generate an appropriate regulated voltage. PCU 117 also provides control information to control the generated operating voltage. In various embodiments, PCU 117 may include a variety of power management logic units (circuits) to perform hardware-based power management. Such power management may be completely processor-controlled (e.g., controlled by various processor hardware and may be triggered by workload and / or power constraints, thermal constraints, or other processor constraints), and / or power management may be performed in response to an external source (e.g., a platform or power management source or system software).

[0035] PCU 117 is illustrated as existing as logic separate from processor 170 and / or processor 180. In other cases, PCU 117 may execute on a given one or more of the cores (not shown) of processor 170 or 180. In some cases, PCU 117 may be implemented as a microcontroller (dedicated or general purpose) or other control logic that is configured to execute its own dedicated power management code (sometimes referred to as P-code). In still other embodiments, the power management operations to be performed by PCU 117 may be implemented external to the processor, such as by a separate power management integrated circuit (PMIC) or another component external to the processor. In still other embodiments, the power management operations to be performed by PCU 117 may be implemented within BIOS or other system software.

[0036] Various I / O devices 114 may be coupled to the first interconnect 116, and an interconnect (bus) bridge 118 that couples the first interconnect 116 to a second interconnect 120. In some embodiments, one or more additional processors 115, such as a coprocessor, a high throughput MIC processor, a GPGPU, an accelerator (e.g., a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array (FPGA), or any other processor, are coupled to the first interconnect 116. In some embodiments, the second interconnect 120 may be a low pin count (LPC) interconnect. Various devices may be coupled to the second interconnect 120, including, for example, a keyboard and / or mouse 122, a communication device 127, and a storage unit circuit 128. The storage unit circuit 128 may be a disk drive or other mass storage device, which in some embodiments may include instructions / code and data 130. In addition, an audio I / O 124 may be coupled to the second interconnect 120. Note that other architectures are possible in addition to the point-to-point architecture described above. For example, a system such as multiprocessor system 100 may implement a multi-drop interconnect or other such architecture rather than a point-to-point architecture.

[0037] Exemplary Core Architectures, Processors, and Computer Architectures

[0038] Processor cores may be implemented in different ways, for different purposes, and in different processors. For example, implementations of these cores may include: 1) general purpose in-order cores, for general purpose computing purposes; 2) high performance general purpose out-of-order cores for general purpose computing purposes; 3) special purpose cores, primarily for graphics and / or scientific (throughput) computing purposes. Implementations of different processors may include: 1) a CPU, including one or more general purpose in-order cores for general purpose computing purposes and / or one or more general purpose out-of-order cores for general purpose computing purposes; and 2) a coprocessor, including one or more special purpose cores primarily for graphics and / or scientific (throughput) purposes. Such different processors lead to different computer system architectures, which may include: 1) coprocessors on separate chips from the CPU; 2) coprocessors on separate dies from the CPU in the same package; 3) coprocessors on the same die as the CPU (in which case such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or as dedicated cores); and 4) systems on a chip, which may include the above-described coprocessors as well as additional functionality on the same die as the described CPU (sometimes referred to as application core(s) or application processor(s). An exemplary core architecture is described next, followed by a description of an exemplary processor and computer architecture.

[0039] Figure 2 A block diagram of an embodiment of a processor 200 is illustrated, which may have more than one core, may have an integrated memory controller, and may have integrated graphics. The solid line box illustrates the processor 200 with a single core 202A, a system agent 210, and a set of one or more interconnected controller unit circuits 216, while the optionally added dashed line box illustrates an alternative processor 200 with multiple cores 202(A)-(N), a set of one or more integrated memory control unit circuits 214 and dedicated logic 208 in the system agent unit circuit 210, and a set of one or more interconnected controller unit circuits 216. Note that the processor 200 may be Figure 1 One of the processors 170 or 180 or the coprocessors 138 or 115.

[0040] Thus, different implementations of processor 200 may include: 1) a CPU, where dedicated logic 208 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown), and cores 202(A)-(N) are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of the two); 2) a coprocessor, where cores 202(A)-(N) are a large number of dedicated cores primarily for graphics and / or scientific (throughput) purposes; and 3) a coprocessor, where cores 202(A)-(N) are a large number of general purpose in-order cores. Thus, processor 200 may be a general purpose processor, a coprocessor, or a special purpose processor, such as, for example, a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit circuit), a high throughput many integrated core (MIC) coprocessor (including 30 or more cores), an embedded processor, etc. The processor may be implemented on one or more chips. Processor 200 may be part of and / or implemented on one or more substrates using any of a number of process technologies, such as BiCMOS, CMOS, or NMOS.

[0041] The memory hierarchy includes one or more levels of cache unit circuits 204(A)-(N) within the cores 202(A)-(N), a set or one or more shared cache unit circuits 206, and external memory (not shown) coupled to the set of integrated memory controller unit circuits 214. The set of one or more shared cache unit circuits 206 may include one or more intermediate level caches (e.g., level 2 (L2), level 3 (L3), level 4 (4), or other levels of cache), such as a last level cache (LLC), and / or combinations thereof. While in some embodiments a ring-based interconnect network circuit 212 interconnects the dedicated logic 208 (e.g., integrated graphics logic), the set of shared cache unit circuits 206, and the system agent unit circuit 210, alternative embodiments use any number of well-known techniques to interconnect such units. In some embodiments, coherency is maintained between one or more of the shared cache unit circuits 206 and the cores 202(A)-(N).

[0042] In some embodiments, one or more of the cores 202(A)-(N) are capable of multithreading. System agent unit circuitry 210 includes those components that coordinate and operate the cores 202(A)-(N). System agent unit circuitry 210 may include, for example, power control unit (PCU) circuitry and / or display unit circuitry (not shown). The PCU may be or may include logic and components required to regulate the power state of the cores 202(A)-(N) and / or the dedicated logic 208 (e.g., integrated graphics logic). The display unit circuitry is used to drive one or more externally connected displays.

[0043] The cores 202(A)-(N) may be homogeneous or heterogeneous with respect to the architectural instruction set; that is, two or more of the cores 202(A)-(N) may be capable of executing the same instruction set, while other cores may be capable of executing only a subset of the instruction set or a different instruction set.

[0044] Exemplary Core Architecture

[0045] In-order and out-of-order core block diagram

[0046] The block diagram of FIG. 3(A) illustrates both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline according to an embodiment of the present invention. The block diagram of FIG. 3(B) illustrates both an exemplary embodiment of an in-order architecture core to be included in a processor and an exemplary register renaming, out-of-order issue / execution architecture core according to an embodiment of the present invention. The solid line boxes in FIG. 3(A)-3(B) illustrate the in-order pipeline and the in-order core, while the optionally added dashed line boxes illustrate the register renaming, out-of-order issue / execution pipeline and core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0047] In FIG. 3(A), the processor pipeline 300 includes a fetch stage 302, an optional length decoding stage 304, a decode stage 306, an optional allocation stage 308, an optional rename stage 310, a dispatch (also called dispatch or issue) stage 312, an optional register read / memory read stage 314, an execute stage 316, a write back / memory write stage 318, an optional exception handling stage 322, and an optional commit stage 324. One or more operations may be performed in each of these processor pipeline stages. For example, during the fetch stage 302, one or more instructions are fetched from the instruction memory, during the decode stage 306, the fetched one or more instructions may be decoded, an address using a forwarding register port (e.g., a load store unit (LSU) address) may be generated, and branch forwarding (e.g., an immediate offset or a link register (LR)) may be performed. In one embodiment, the decode stage 306 and the register read / memory read stage 314 may be combined into one pipeline stage. In one embodiment, during the execute stage 316, decoded instructions may be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AHB) interface may be performed, multiplication and addition operations may be performed, arithmetic operations with branch results may be performed, and the like.

[0048] As an example, the exemplary register renaming, out-of-order issue / execution core architecture may implement pipeline 300 as follows: 1) instruction fetch 338 performs fetch and length decode stages 302 and 304; 2) decode unit circuit 340 performs decode stage 306; 3) rename / allocator unit circuit 352 performs allocation stage 308 and rename stage 310; 4) scheduler unit circuit 356 performs schedule stage 312; 5) physical register file unit circuit 358 and memory unit circuit 370 perform register read / memory read stage 314; execution cluster 360 performs execution stage 316; 6) memory unit circuit 370 and physical register file unit circuit 358 perform write back / memory write stage 318; 7) various units (unit circuits) may be involved in exception handling stage 322; and 8) retirement unit circuit 354 and physical register file unit circuit 358 perform commit stage 324.

[0049] 3(B) shows that the processor core 390 includes a front end unit circuit 330 coupled to an execution engine unit circuit 350, and both are coupled to a memory unit circuit 370. The core 390 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. As yet another option, the core 390 can be a special-purpose core, such as, for example, a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, and the like.

[0050] The front end unit circuit 330 may include a branch prediction unit circuit 332, which is coupled to an instruction cache unit circuit 334, which is coupled to an instruction translation lookaside buffer (TLB) 336, which is coupled to an instruction fetch unit circuit 338, which is coupled to a decode unit circuit 340. In one embodiment, the instruction cache unit circuit 334 is included in the memory unit circuit 370 instead of the front end unit circuit 330. The decode unit circuit 340 (or decoder) may decode the instruction and generate one or more micro-operations, microcode entry points, microinstructions, other instructions or other control signals as outputs, which are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decode unit circuit 340 may also include an address generation unit circuit (AGU, not shown). In one embodiment, the AGU uses the forwarded register port to generate the LSU address, and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc.). The decode unit circuit 340 may be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, a lookup table, a hardware implementation, a programmable logic array (PLA), a microcode read only memory (ROM), and the like. In one embodiment, the core 390 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in the decode unit circuit 340 or otherwise within the front end unit circuit 330). In one embodiment, the decode unit circuit 340 includes a micro-op or operation cache (not shown) to hold / cache decoded operations, micro-tags, or micro-ops generated during decoding or other stages of the processor pipeline 300. The decode unit circuit 340 may be coupled to the rename / allocator unit circuit 352 in the execution engine unit circuit 350.

[0051] The execution engine circuit 350 includes a rename / allocator unit circuit 352, which is coupled to a retirement unit circuit 354 and a set of one or more scheduler circuits 356. The scheduler circuit 356 represents any number of different schedulers, including reservation stations, central instruction windows, and the like. In some embodiments, the scheduler circuit 356 may include an arithmetic logic unit (ALU) scheduler / scheduling circuit, an ALU queue, an arithmetic generation unit (AGU) scheduler / scheduling circuit, an AGU queue, and the like. The scheduler circuit 356 is coupled to a physical register file circuit 358. Each of the physical register file circuits 358 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., an instruction pointer that is the address of the next instruction to be executed), and the like. In one embodiment, the physical register file unit circuit 358 includes a vector register unit circuit, a write mask register unit circuit, and a scalar register unit circuit. These register units can provide architectural vector registers, vector mask registers, general registers, etc. The physical register file unit circuit 358 overlaps with the retirement unit circuit 354 (also called a retirement queue or retirement queue) to illustrate various ways that register renaming and out-of-order execution can be implemented (e.g., using (one or more) reorder buffers (ROB) and (one or more) retirement register files; using (one or more) future stacks, (one or more) history buffers, and (one or more) retirement register files; using register maps and pools of registers; etc.). The retirement unit circuit 354 and the physical register file circuit 358 are coupled to (one or more) execution clusters 360. The (one or more) execution clusters 360 include a set of one or more execution unit circuits 362 and a set of one or more memory access circuits 364. Execution unit circuitry 362 may perform various arithmetic, logical, floating point, or other types of operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include several execution units or execution unit circuits dedicated to a particular function or set of functions, other embodiments may include only one execution unit circuit or multiple execution units / execution unit circuits that all perform all functions.Scheduler circuitry 356, physical register file unit circuitry 358, and execution cluster(s) 360 are shown as possibly multiple because some embodiments create separate pipelines for certain types of data / operations (e.g., a scalar integer pipeline, a scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipeline, and / or a memory access pipeline, each with its own scheduler circuitry, physical register file unit circuitry, and / or execution cluster—and in the case of a separate memory access pipeline, some embodiments are implemented where only the execution cluster of this pipeline has memory access unit circuitry 364). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, while the rest are in-order.

[0052] In some embodiments, the execution engine unit circuit 350 may perform load store unit (LSU) address / data pipelining to an advanced microcontroller bus (AHB) interface (not shown), as well as address stage and writeback, data stage loads, stores, and branches.

[0053] The set of memory access circuits 364 are coupled to the memory cell circuit 370, which includes a data TLB unit circuit 372, which is coupled to a data cache circuit 374, which is coupled to a level 2 (L2) cache circuit 376. In an exemplary embodiment, the memory access unit circuit 364 may include a load unit circuit, a storage address unit circuit, and a storage data unit circuit, each of which is coupled to the data TLB circuit 372 in the memory cell circuit 370. The instruction cache circuit 334 is further coupled to the level 2 (L2) cache unit circuit 376 in the memory cell circuit 370. In one embodiment, the instruction cache 334 and the data cache 374 are combined into a single instruction and data cache (not shown) in the L2 cache unit circuit 376, the level 3 (L3) cache unit circuit (not shown), and / or the main memory. The L2 cache unit circuit 376 is coupled to one or more other levels of cache and ultimately coupled to the main memory.

[0054] Core 390 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set; the ARM instruction set (with optional additional extensions, such as NEON)), including the instruction(s) described herein. In one embodiment, core 390 includes logic to support packed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using packed data.

[0055] Exemplary Execution Unit Circuit

[0056] Figure 4 An embodiment of an execution unit circuit is illustrated, such as the execution unit circuit 362 of FIG. 3(B). As shown, the execution unit circuit 362 may include one or more ALU circuits 401, vector / SIMD unit circuits 403, load / store unit circuits 405, and / or branch / jump unit circuits 407. The ALU circuit 401 performs integer arithmetic and / or Boolean operations. The vector / SIMD unit circuit 403 performs vector / SIMD operations on compressed data (e.g., SIMD / vector registers). The load / store unit circuit 405 executes load and store instructions to load data from a memory into a register, or store data from a register to a memory. The load / store unit circuit 405 may also generate addresses. The branch / jump unit circuit 407 causes a branch or jump to a certain memory address depending on the instruction. The floating-point unit (FPU) circuit 409 performs floating-point arithmetic. The width of the execution unit circuit 362 varies depending on the embodiment and may be in the range of 16 bits to 1024 bits. In some embodiments, two or more smaller execution units are logically combined to form a larger execution unit (eg, two 128-bit execution units are logically combined to form a 256-bit execution unit).

[0057] Exemplary Register Architecture

[0058] Figure 5 5 is a block diagram of a register architecture 500 according to some embodiments. As shown, there are vector / SIMD registers 510, whose widths vary from 128 bits to 1024 bits. In some embodiments, vector / SIMD registers 510 are physically 512 bits, and depending on the mapping, only some low-order bits are used. For example, in some embodiments, vector / SIMD registers 510 are 512-bit ZMM registers: the low-order 256 bits are used for YMM registers, and the low-order 128 bits are used for XMM registers. Therefore, there is an overlay of registers. In some embodiments, the vector length field selects between the maximum length and one or more other shorter lengths, wherein each such shorter length is half the length of the previous length; scalar operations are operations performed on the lowest-order data element position in the ZMM / YMM / XMM register; higher-order data element positions are either kept the same as they were before the instruction, or are zeroed, depending on the embodiment.

[0059] In some embodiments, the register architecture 500 includes a write mask / predicate register 515. For example, in some embodiments, there are 8 write mask / predicate registers (sometimes referred to as k0 to k7), each of which is 16 bits, 32 bits, 64 bits, or 128 bits in size. The write mask / predicate register 515 can allow merging (e.g., allowing any set of elements in the destination to be exempted from updates during the execution of any operation) and / or zeroing (e.g., a zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation). In some embodiments, each data element position in a given write mask / predicate register 515 corresponds to a data element position in the destination. In other embodiments, the write mask / predicate register 515 is scalable and consists of a set number of enable bits for a given vector element (e.g., 8 enable bits for each 64-bit vector element).

[0060] The register architecture 500 includes a plurality of general purpose registers 525. These registers may be 16 bits, 32 bits, 64 bits, etc., and may be used for scalar operations. In some embodiments, these registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 to R15.

[0061] In some embodiments, register architecture 500 includes scalar floating point registers 545, which are used for scalar floating point operations on 32 / 64 / 80-bit floating point data using the x87 instruction set extension, or as MMX registers to perform operations on 64-bit packed integer data, and to hold operands for some operations performed between MMX and XMM registers.

[0062] One or more flag registers 540 (e.g., EFLAGS, RFLAGS, etc.) store status and control information for arithmetic, comparison, and system operations. For example, one or more flag registers 540 can store conditional code information, such as carry, parity, auxiliary carry, zero, sign, and overflow. In some embodiments, one or more flag registers 540 are referred to as program status and control registers.

[0063] Segment registers 520 contain segment points for accessing memory. In some embodiments, these registers are referenced by the names CS, DS, SS, ES, FS, and GS.

[0064] Machine-specific registers (MSRs) 535 control and report processor performance. Most MSRs 535 handle system-related functions and are not accessible to applications. Machine check registers 560 consist of control, status, and error reporting MSRs used to detect and report hardware errors.

[0065] One or more instruction pointer registers 530 store instruction pointer values. Control register(s) 555 (e.g., CR0-CR4) determine the operating mode of the processor (e.g., processor 170, 180, 138, 115, and / or 200) and the characteristics of the task currently being executed. Debug registers 550 control and allow monitoring of debug operations of a processor or core.

[0066] Memory management registers 565 specify the location of data structures used in protected mode memory management. These registers may include the GDTR, IDRT, task register, and LDTR registers.

[0067] Alternative embodiments of the present invention may use wider or narrower registers. In addition, alternative embodiments of the present invention may use more, fewer or different register files and registers.

[0068] Instruction Set

[0069] An instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of the bits) to specify the operation to be performed (e.g., opcode) and the (one or more) operands and / or other (one or more) data fields (e.g., mask) on which the operation is to be performed, etc. Some instruction formats are further decomposed by the definition of instruction templates (or subformats). For example, an instruction template of a given instruction format may be defined as having different subsets of the fields of the instruction format (the included fields are usually in the same order, but at least some have different bit positions because fewer fields are included) and / or defined as having a given field interpreted in a different manner. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, expressed in a given instruction template in the instruction format), and includes fields for specifying the operation and the operand. For example, an exemplary ADD instruction has a specific opcode and instruction format, which includes an opcode field to specify the opcode and an operand field to select the operand (source 1 / destination and source 2); and the appearance of this ADD instruction in the instruction stream will have specific content in the operand field to select the specific operand.

[0070] Example instruction format

[0071] The embodiments of the (one or more) instructions described herein may be implemented in different formats. In addition, exemplary systems, architectures, and pipelines are described in detail below. Embodiments of the (one or more) instructions may be executed on such systems, architectures, and pipelines, but are not limited to those described in detail.

[0072] Figure 6 An embodiment of an instruction format is illustrated. As shown, an instruction may include multiple components, including but not limited to one or more fields for: one or more prefixes 601, an opcode 603, addressing information 605 (e.g., a register identifier, memory addressing information, etc.), a displacement value 607, and / or an immediate value 609. Note that some instructions utilize some or all of the fields of the format, while other instructions may only use the opcode 603 field. In some embodiments, the illustrated order is the order in which these fields are to be encoded, however, it should be understood that in other embodiments, these fields may be encoded in a different order, combined, etc.

[0073] (One or more) prefix fields 601 can modify instructions when used. In some embodiments, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc.), to provide section override (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc.), to perform bus lock operations, and / or change the operation object (e.g., 0x66) and address size (e.g., 0x67). Some instructions require mandatory prefixes (e.g., 0x66, 0xF2, 0xF3, etc.). Some of these prefixes can be considered as "traditional" prefixes. Other prefixes (one or more examples of which are described in detail herein) indicate and / or provide further capabilities, such as specifying specific registers, etc. These other prefixes are usually followed by the "traditional" prefix.

[0074] The opcode field 603 is used to at least partially define the operation to be performed when the instruction is decoded. In some embodiments, the length of the primary opcode encoded in the opcode field 603 is 1, 2 or 3 bytes. In other embodiments, the primary opcode can be a different length. The additional 3-bit opcode field is sometimes encoded in another field.

[0075] The addressing field 605 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. Figure 7An embodiment of the addressing field 605 is illustrated. In this illustration, an optional ModR / M byte 702 and an optional Scale, Index, Base (SIB) byte 704 are shown. The ModR / M byte 702 and SIB byte 704 are used to encode up to two operands of an instruction, each operand being a direct register or an effective memory address. Note that each of these fields is optional, i.e., not all instructions include one or more of these fields. The MOD R / M byte 702 includes a MOD field 742, a Register field 744, and an R / M field 746.

[0076] The content of MOD field 742 distinguishes between memory access and non-memory access modes. In some embodiments, when the value of MOD field 742 is b11, register direct addressing mode is utilized, otherwise register indirect addressing is used.

[0077] Register field 744 may encode a destination register operand or a source register operand, or may encode an opcode extension, and may not be used to encode any instruction operand. The contents of register index field 744 specify directly or through address generation the location (in a register or in memory) of the source or destination operand. In some embodiments, register field 744 is supplemented with additional bits from a prefix (e.g., prefix 601) to allow greater addressing.

[0078] R / M field 746 may be used to encode an instruction operand that references a memory address, or may be used to encode a destination register operand or a source register operand. Note that R / M field 746 may be combined with MOD field 742 in some embodiments to specify an addressing mode.

[0079] SIB byte 704 includes a scaling field 752, an index field 754, and a base address field 756 for address generation. Scaling field 752 indicates a scaling factor. Index field 754 specifies the index register to be used. In some embodiments, index field 754 is supplemented with additional bits from a prefix (e.g., prefix 601) to allow for greater addressing. Base address field 756 specifies the base address register to be used. In some embodiments, base address field 756 is supplemented with additional bits from a prefix (e.g., prefix 601) to allow for greater addressing. In practice, the contents of scaling field 752 allow the contents of index field 754 to be scaled for memory address generation (e.g., for memory addresses using 2 缩放 × index + base address generation).

[0080] Some addressing forms use displacement values ​​to generate memory addresses. For example, 缩放× index + base address + displacement, index × scaling + displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. to generate a memory address. The displacement can be a value of 1 byte, 2 bytes, 4 bytes, etc. In some embodiments, the displacement field 607 provides this value. In addition, in some embodiments, the displacement factor usage is encoded in the MOD field of the addressing field 605, which indicates a compressed displacement scheme, for which the displacement value is calculated by multiplying disp8 in combination with a scaling factor N, which is determined based on the vector length, the value of the b bit, and the input element size of the instruction. The displacement value is stored in the displacement field 607.

[0081] In some embodiments, the immediate value field 609 specifies an immediate value for the instruction. The immediate value may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, etc.

[0082] Figure 8 An embodiment of a first prefix 601(A) is illustrated. In some embodiments, the first prefix 601(A) is an embodiment of a REX prefix. Instructions using this prefix may specify general registers, 64-bit packed data registers (e.g., single instruction, multiple data (SIMD) registers or vector registers), and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15).

[0083] Instructions using the first prefix 601(A) can specify up to three registers using a 3-bit field, depending on the format: 1) using the reg field 744 and the R / M field 746 of the Mod R / M byte 702; 2) using the Mod R / M byte 702 with the SIB byte 704, including using the reg field 744 and the base field 756 and index field 754; or 3) using the register field of the opcode.

[0084] In the first prefix 601 (A), bit positions 7:4 are set to 0100. Bit position 3 (W) may be used to determine the operand size, but may not determine the operand width alone. Thus, when W=0, the operand size is determined by the code segment descriptor (CS.D), and when W=1, the operand size is 64 bits.

[0085] Note that adding another bit allows addressing 16 (2 4 ) registers, while the separate MOD R / M reg field 744 and MOD R / MR / M field 746 can only address 8 registers each.

[0086] In the first prefix 601(A), bit position 2 (R) may be an extension of the MOD R / M reg field 744 and may be used to modify the Mod R / M reg field 744 when the field encodes a general register, a 64-bit packed data register (e.g., an SSE register), or a control or debug register. When the Mod R / M byte 702 specifies other registers or defines an extended opcode, R is ignored.

[0087] Bit position 1 (X) X bits may modify the SIB byte index field 754 .

[0088] Bit position B (B) B may modify the base address in Mod R / MR / M field 746 or SIB Byte Base Address field 756; or it may modify the opcode register field used to access a general register (eg, general register 525).

[0089] 9(A)-(D) illustrate an embodiment of how the R, X, and B fields of the first prefix 601(A) are used. FIG. 9(A) illustrates that when the SIB byte 704 is not used for memory addressing, the R and B from the first prefix 601(A) are used to extend the reg field 744 and the R / M field 746 of the MOD R / M byte 702. FIG. 9(B) illustrates that when the SIB byte 704 is not used, the R and B from the first prefix 601(A) are used to extend the reg field 744 and the R / M field 746 of the MOD R / M byte 702 (register-register addressing). FIG. 9(B) illustrates that when the SIB byte 704 is used for memory addressing, the R, X, and B from the first prefix 601(A) are used to extend the reg field 744 and the index field 754 and the base address field 756 of the MOD R / M byte 702. FIG. 9(D) illustrates that the B from the first prefix 601 (A) is used to extend the reg field 744 of the MOD R / M byte 702 when the register is encoded in the opcode 603 .

[0090] Figure 10 (A)-(B) illustrates an embodiment of the second prefix 601 (B). In some embodiments, the second prefix 601 (B) is an embodiment of a VEX prefix. The second prefix 601 (B) encoding allows instructions to have more than two operands, and allows SIMD vector registers (e.g., vector / SIMD registers 2410) to be longer than 64 bits (e.g., 128 bits and 256 bits). The use of the second prefix 601 (B) provides a syntax for three operands (or more). For example, a previous two-operand instruction performs an operation such as A=A+B, which overwrites the source operand. The use of the second prefix 601 (B) enables the operands to perform non-destructive operations, such as A=B+C.

[0091] In some embodiments, the second prefix 601(B) has two forms: a two-byte form and a three-byte form. The two-byte second prefix 601(B) is mainly used for 128-bit, scalar, and some 256-bit instructions; while the three-byte second prefix 601(B) provides a compact replacement for the first prefix 601(A) and 3-byte opcode instructions.

[0092] Figure 10 (A) illustrates an embodiment of the two-byte form of the second prefix 601 (B). In one example, the format field 1001 (byte 0 1003) contains the value C5H. In one example, byte 1 1005 includes an "R" value in bit [7]. This value is the complement of the same value of the first prefix 601 (A). Bit [2] is used to specify the length (L) of the vector (wherein the value of 0 is a scalar or 128-bit vector, and the value of 1 is a 256-bit vector). Bit [1:0] provides an operation code extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form, valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form, used for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0093] Instructions using this prefix may use the Mod R / MR / M field 746 to encode instruction operands that reference memory addresses, or to encode destination register operands or source register operands.

[0094] Instructions using this prefix may use the Mod R / M reg field 744 to encode either a destination register operand or a source register operand, and are treated as an opcode extension and are not used to encode any instruction operand.

[0095] For instruction syntax supporting four operands, vvvv, Mod R / MR / M field 746 and Mod R / M reg field 744 encode three of the four operands. Bits [7:4] of immediate 609 are then used to encode the third source register operand.

[0096] FIG. 10 (B) illustrates an embodiment of a three-byte form of the second prefix 601 (B). In one example, the format field 1011 (byte 0 1013) contains the value C4H. Byte 1 1015 includes "R", "X" and "B" in bit [7:5], which are the complements of the same value of the first prefix 601 (A). Bit [4:0] (shown as mmmm) of byte 1 1015 includes content to encode one or more implicit leading opcode bytes as needed. For example, 00001 means 0FH leading opcode, 00010 means 0F38H leading opcode, 00011 means leading 0F3AH opcode, and so on.

[0097] Bit [7] of byte 2 1017 is used similarly to W of the first prefix 601 (A), including helping to determine the size of operands that can be promoted. Bit [2] is used to specify the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector, and a value of 1 is a 256-bit vector). Bits [1:0] provide opcode extensibility equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). Bits [6:3], shown as vvvv, can be used to: 1) encode the first source register operand, which is specified in inverted (inverse) form, valid for instructions with 2 or more source operands; 2) encode the destination register operand, which is specified in inverse form for certain vector shifts; or 3) do not encode any operand, this field is reserved and should contain a value, such as 1111b.

[0098] Instructions using this prefix may use the Mod R / MR / M field 746 to encode instruction operands that reference memory addresses, or to encode destination register operands or source register operands.

[0099] Instructions using this prefix may use the Mod R / M reg field 744 to encode either a destination register operand or a source register operand, and are treated as an opcode extension and are not used to encode any instruction operand.

[0100] For instruction syntax supporting four operands, vvvv, Mod R / MR / M field 746 and Mod R / M reg field 744 encode three of the four operands. Bits [7:4] of immediate 609 are then used to encode the third source register operand.

[0101] Fig.11 An embodiment of a third prefix 601(C) is illustrated. In some embodiments, the first prefix 601(A) is an embodiment of an EVEX prefix. The third prefix 601(C) is a four-byte prefix.

[0102] The third prefix 601 (C) can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some embodiments, write masks / operation masks are used (see the discussion of registers in the previous figures, e.g., Figure 5 ) or predicted instructions utilize this prefix. The operation mask register allows conditional processing or selection control. Operation mask instructions whose source / destination operands are operation mask registers and treat the contents of the operation mask register as a single value are encoded using the second prefix 601 (B).

[0103] The third prefix 601(C) may encode functionality specific to the instruction class (e.g., a packed instruction with “load+operation” semantics may support an embedded broadcast functionality, a floating-point instruction with rounding semantics may support a static rounding functionality, a floating-point instruction with non-rounding arithmetic semantics may support a “suppress all exceptions” functionality, etc.).

[0104] The first byte of the third prefix 601 (C) is the format field 1111, which in one example has a value of 62 H. The subsequent bytes are referred to as payload bytes 1115-1119, and together form a 24-bit value of P[23:0], providing specific capabilities (described in detail herein) in the form of one or more fields.

[0105] In some embodiments, P[1:0] of payload byte 1119 is the same as the two mmmm bits in the lower order. In some embodiments, P[3:2] is reserved. Bit P[4] (R') allows access to the upper 16 vector register sets when combined with P[7] and ModR / M reg field 744. When SIB type addressing is not required, P[6] may also provide access to the upper 16 vector registers. P[7:5] consists of R, X, and B, which are the operand specifier modifier bits for vector registers, general registers, and memory addressing, and when combined with ModR / M register field 744 and ModR / MR / M field 746, allows access to the next set of 8 registers outside the lower 8 registers. P[9:8] provides opcode extension equivalent to some traditional prefixes (e.g., 00=no prefix, 01=66H, 10=F3H, and 11=F2H). P

[10] is a fixed value of 1 in some embodiments. P[14:11], shown as vvvv, can be used to: 1) encode a first source register operand, which is specified in inverted (complement) form, valid for instructions with 2 or more source operands; 2) encode a destination register operand, which is specified in complement form, used for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a value, such as 1111b.

[0106] P

[15] is similar to W of the first prefix 601 (A) and the second prefix 611 (B), and can be used as an opcode extension bit or an operand size increase.

[0107] P[18:16] specifies the index of a register in the operation mask (write mask) register (e.g., write mask / predicate register 515). In one embodiment of the invention, the particular value aaa=000 has special behavior, implying that no operation mask is used for the particular instruction (this can be implemented in a variety of ways, including using an operation mask hardwired to all ones or hardware that bypasses the masking hardware). When merging, the vector mask allows any set of elements in the destination to be protected from updates during the execution of any operation (specified by the basic operation and the enhanced operation); in another embodiment, the old value of each element of the destination whose corresponding mask bit has a 0 is preserved. In contrast, when the zeroing vector mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the basic operation and the enhanced operation); in one embodiment, the elements of the destination are set to 0 when the corresponding mask bit has a value of 0. A subset of this functionality is the ability to control the vector length of the operation performed (i.e., the span of elements modified, from first to last); however, the elements modified do not have to be consecutive. Thus, the operation mask field enables a subset of vector operations, including loads, stores, arithmetic, logical, etc. Although embodiments of the invention are described in which the contents of the operation mask field select which of several operation mask registers contains the operation mask to be used (whereby the contents of the operation mask field indirectly identify the masking to be performed), alternative embodiments instead or in addition allow the contents of the mask write field to directly specify the masking to be performed.

[0108] P

[19] can be combined with P[14:11] to encode a second source vector register in a non-destructive source syntax that can utilize P

[19] to access the upper 16 vector registers. P

[20] encodes a variety of features that vary across different classes of instructions and can affect the meaning of the vector length / rounding control specifier field (P[22:21]). P

[23] indicates support for merge-write masking (e.g., when set to 0) or support for zeroing and merge-write masking (e.g., when set to 1).

[0109] An exemplary embodiment of the encoding of registers in instructions using the third prefix 601 (C) is detailed in the table below.

[0110]

[0111] Table 1: 32-register support in 64-bit mode

[0112]

[0113]

[0114] Table 2: Encoding register specifiers in 32-bit mode

[0115] [2:0] REG. Type Common Uses REG ModR / M reg k0-k7 source VVVV vvvv k0-k7 Source 2 RM ModR / MR / M k0-7 Source 1 {k1] aaa <![CDATA[k0 1 -k7]]> Operation Mask

[0116] Table 3: Operation Mask Register Specifier Encoding

[0117] Program code 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 present application, a processing system includes any system with a processor, such as a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0118] Program code can be implemented with high-level procedural or object-oriented programming languages ​​to communicate with the processing system. If desired, program code can also be implemented with assembly or machine language. In fact, the mechanism described herein is not limited to any specific programming language in scope. In any case, the language can be a compiled language or an interpreted language.

[0119] Embodiments of the mechanisms disclosed herein may be implemented with hardware, software, firmware, or a combination of such implementations. Embodiments of the present invention may be implemented as a computer program or program code executed on a programmable system including 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.

[0120] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium representing various logic within a processor, which, when read by a machine, causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible machine-readable medium and provided to various customers or manufacturing facilities to be loaded into fabrication machines that actually fabricate the logic or processor.

[0121] Such machine-readable storage media may include, but are not limited to, a non-transitory tangible arrangement of an article manufactured or formed by a machine or device, including storage media such as a hard disk, any other type of disk (including floppy disks, optical disks, compact disk read-only memory (CD-ROM), compact disk rewritable (CD-RW), and magneto-optical disks), 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 medium suitable for storing electronic instructions.

[0122] Therefore, embodiments of the present invention also include non-transitory tangible machine-readable media containing instructions or design data, such as hardware description language (HDL), that define the features of the structures, circuits, devices, processors and / or systems described herein. Such embodiments may also be referred to as program products.

[0123] Emulation (including binary translation, code deformation, etc.)

[0124] In some cases, the instruction converter may be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter may translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation), deform, simulate or otherwise convert instructions to one or more other instructions to be processed by the core. The instruction converter may be implemented with software, hardware, firmware or a combination thereof. The instruction converter may be on the processor, outside the processor, or partly on the processor and partly outside the processor.

[0125] Fig.12The block diagram of compares the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to some implementations. In the illustrated embodiment, the instruction converter is a software instruction converter, although alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig.12 A program in a high-level language 1202 is shown to be compiled using a first ISA compiler 1204 to generate first ISA binary code 1206 that is natively executable by a processor 1216 having at least one first instruction set core. The processor 1216 having at least one first ISA instruction set core represents any processor that can execute programs that are compatible with an Intel processor having at least one first ISA instruction set core by compatibly executing or otherwise processing (1) a substantial portion of the instruction set of the first ISA instruction set core or (2) an object code version of an application or other software that is targeted to run on an Intel processor having at least one first ISA instruction set core. The first ISA compiler 1204 represents a compiler operable to generate first ISA binary code 1206 (e.g., object code) that can be executed on a processor 1216 having at least one first ISA instruction set core with or without additional linking processing.

[0126] Similarly, Fig.12 It is shown that the program of the high-level language 1202 can be compiled using an alternative instruction set compiler 1208 to generate an alternative instruction set binary code 1210, which can be executed natively by a processor 1214 without a first ISA instruction set core. The instruction converter 1212 is used to convert the first ISA binary code 1206 into a code that can be executed natively by a processor 1214 without a first ISA instruction set core. This converted code is unlikely to be the same as the alternative instruction set binary code 1210, because an instruction converter that can do this is difficult to make; however, the converted code will implement general operations and be composed of instructions from an alternative instruction set. Thus, the instruction converter 1212 represents software, firmware, hardware, or a combination thereof, which allows a processor or other electronic device that does not have a first ISA instruction set processor or core to execute the first ISA binary code 1206 through simulation, emulation, or any other process.

[0127] Method and apparatus for processor trace trigger tracing

[0128] The processor includes dedicated execution trace hardware to perform instruction stream trace operations. For example, trace hardware is included in x86 processors, ARM-based processors, and other types of processors (including fixed-function processors and programmable accelerators).

[0129] Some processors implement trace functionality using a combination of dedicated trace hardware and instruction set architecture (ISA) extensions that can take advantage of the trace hardware. For example, Intel Processor Trace (Intel PT) is an extension of the Intel architecture that captures information about software execution using dedicated hardware facilities that cause only minimal performance disruption to the software being traced. This information is collected in various data packets that are processed by software decoders to perform control flow tracing. The packets include timing, program flow information (e.g., branch targets, branch taken / not taken indications), and pattern-related information induced by the program (e.g., transactional synchronization extensions (TSX) state transitions, CR3 changes). These packets can be buffered internally before being sent to the memory subsystem or other output mechanisms available on the platform. Debug software can process the trace data and reconstruct the program flow. Current generations of processors include support for a variety of trace sources, including those accessed by instructions such as PTWRITE and power event traces, which expose core and thread-level sleep state and power-down transition information to the trace function.

[0130] Embodiments of the present invention include new tracing hardware that allows new conditions and events such as performance monitoring events, performance monitoring event overflows, and debug register matches to be used as trigger events for tracing operations. The tracing hardware can be configured to perform actions in response to these trigger events, such as pausing / resume tracing and generating new data packets (TRIGs) associated with the triggering event, with IP attribute details in the trace. These new features are sometimes referred to herein as Trace Trigger Tracing (TTT).

[0131] A. Example of processor trace

[0132] Fig.13 13 is a block diagram of one embodiment of a processor 1302 and random access memory (RAM) 1330. The processor 1302 includes a cache memory 1306, a power management unit 1308, one or more cores 1312, and a processor 1302 that is configured to store and manage memory 1306. i (For example, 13121,13122,...1312 N), and may include additional logic (not shown). Core 13121 includes fetch logic 13041, out-of-order logic (OOO) 13141, execution logic 13161, and retirement unit 13171, which includes PT logic 13181 with PTWRITE logic 13201. Retirement unit 13171 also includes processor trace (PT) cache memory 13101.

[0133] In operation, the program may be compiled, and the executable code generated by the compilation may be stored in RAM 1330, retrieved by fetch logic 13041 and input to OOO 13141 of core 13121. Each instruction of the executable code may be input by OOO 13141 to execution logic 13161 of core 13121.

[0134] A program may include zero, one, or more PTWRITE instructions (e.g., added to the original program by a user (e.g., a programmer)). Each PTWRITE instruction, when executed, will obtain the operand value of the operand specified by the PTWRITE instruction, for example, a specific data value that may be stored in a specified register, a specified memory location, or an immediate value. The operand value may be used for debugging purposes. The execution of the PTWRITE instruction has little or no effect on the execution of other parts of the program (e.g., little or no effect on the execution of the original program). That is, the PTWRITE instruction will not introduce significant delays into the execution of the original program because it simply retrieves the operand value of the specified operand.

[0135] Each data value retrieved by executing a corresponding PTWRITE instruction may be used along with other processor trace information for program analysis to, for example, debug the program and / or improve execution efficiency, energy efficiency, etc. (eg, "tune" the program).

[0136] Within the PT logic 13181, the PTWRITE logic 13201 will detect the execution of each PTWRITE instruction. For each PTWRITE instruction executed by the execution logic 13161, when PTWRITE is enabled, the PTWRITE logic 13201 will formulate a corresponding PTWRITE packet, for example, adding a PTWRITE packet header to the operand value retrieved by the PTWRITE packet. The PTWRITE packet header can be used to identify the PTWRITE packet, for example, to distinguish it from all other PT packets.

[0137] After the execution logic 13161 executes a (non-PTWRITE) instruction, the PT logic 13181 may generate processor trace packets. Each PT packet will provide information about the result of the instruction, such as the branch taken for a branch instruction, or other diagnostic data. For example, the PT packets generated by the PT logic 13181 may include control flow traces, data address traces, data value traces, and may also include other trace packets.

[0138] PT logic 13181 may store each PTWRITE packet output by PTWRITE logic 13201, as well as PT packets generated by PT logic 13181. PT logic 13181 may include the PTWRITE packet in the processor trace, correlating it with the PT packet, so that additional timestamp correlation is unnecessary. In some embodiments, the PTWRITE packet will include an instruction pointer (IP) to the corresponding PTWRITE instruction, and the IP may be used to achieve time correlation of the PTWRITE packet with the PT packet.

[0139] PT logic 13181 will output a processor trace (PT), including packets generated by PT logic 13181, including PTWRITE packets generated by PTWRITE logic 13201. The PT may be stored in, for example, PT cache 13101, or the PT may be stored in RAM 1330 for long term storage that may be useful to a user during debugging work.

[0140] Fig.14 14 is a block diagram of a processor according to an embodiment. The processor 1402 includes a cache memory 1406, a power management unit 1408, and one or more cores 14121-1412 N The core 14121 includes fetch logic 14041 , execute logic 14141 , and a retirement unit 14171 , which includes processor trace (PT) logic 14181 , which includes PTWRITE logic 14201 . The retirement unit 14171 also includes a processor trace (PT) cache 14101 .

[0141] In operation, the core 14121 may receive (e.g., via the fetch logic 14041) executable code, e.g., a program that has been compiled into executable code, e.g., instructions to be executed by the core 14121. The programmer may have included one or more PTWRITE instructions within the program, e.g., to retrieve operand values ​​at specific points in the program's execution. The PTWRITE instructions may be executed "transparently," e.g., execution of the original program (e.g., before any PTWRITE instructions were included) is substantially unaffected by the execution of the PTWRITE instructions.

[0142] Execution logic 14141 may execute each instruction of the executable code. For example, a portion of the executable code may include instructions 1422, 1424, 1426, 1428, and 1430. Each instruction has a corresponding instruction pointer, such as an address identified with the instruction. Fig.14 As shown, instruction 1422 has IP=0001, instruction 1424 has IP=0002, instruction 1426 has IP=0003, instruction 1428 has IP=0004, and instruction 1430 has IP=0005.

[0143] Processor trace (PT) logic 14181 may generate no processor trace packets, or may generate one (or more) processor trace packets as each instruction is executed. PT logic 14181 may generate PT packets that may include, for example, indications of taken branches (direct or indirect branches) or not taken branches, or other result information based on the execution of the corresponding program instruction. Fig.14 In the example shown, executed instructions 1422, 1424, 1426, and 1430 each cause a respective PT packet 1432, 1434, 1436, and 1440 to be generated. Execution of the PTWRITE instruction 1428 results in the retrieval of the value of the operand M1 (e.g., the value D1 stored at the storage location M1), and triggers the PTWRITE logic 14201 to form a PTWRITE packet 1438. The PTWRITE packet 1438 will include the value D1 stored at the storage location M1, and may optionally include the IP of the PTWRITE instruction 1428, e.g., IP=0004. The retrieved quantity D1 will be "packed", e.g., the PTWRITE logic 14201 will include the retrieved quantity D1 in the packet and provide a packet header that identifies the packet as a PTWRITE packet. In some embodiments, the instruction pointer ( Fig.14 The order of the PT packets to be stored may correspond to the order of execution and may indicate the temporal relationship between the operand values ​​in the PTWRITE packet and the execution order of the non-PTWRITE instructions.

[0144] The PT logic 14201 may insert a PTWRITE packet (generated by the PTWRITE logic 14201) into a processor trace including the PT packet. The processor trace, e.g., the entirety of the PT packet and the interleaved PTWRITE packets, will be output to the PT cache 14101. Alternatively or after being stored in the PT cache 14101, the processor trace may be stored in a long-term storage device (e.g., RAM). The programmer may utilize the processor trace to analyze the program, e.g., to debug, tune the program to improve execution efficiency, and the like.

[0145] Fig.15 Additional processor trace operations are illustrated that are performed in processor 1402. Specifically, Fig.15 Selected processor elements for implementing processor core power event tracing are illustrated, including core 1412 with front end 1504 and trace unit 1506, power control unit 1508, memory management unit 1510, memory 1512, and trace configuration registers 1514. Trace unit 1506 may include components of processor trace logic 14181 described above.

[0146] As described above, mobile computing platforms such as ultrabooks, 2:1 (laptop and tablet in one device), tablets, and smartphones, among others, may utilize batteries. Power management may be used to manage battery life in mobile computing platforms and other systems. In the processor 1402, power management may involve decisions made by the power control unit 1508 to reduce power consumption without negatively affecting the overall performance of the processor 1402. For example, the power management architecture in the processor 1402 may provide different types of sleep states for the processor 1402 or the core 1412. The sleep state may be distinguished from the awake state by taking one or more measures to save power. One type of sleep state may be a simple pause in the instruction pipeline, where the core 1412 stops executing instructions for a period of time, while the voltage and clock frequency remain unchanged relative to the awake state. Another type of sleep state may be a sleep state in which certain portions of the processor 1402 (including the core 1412) are physically powered off, and the processor clock is stopped or set to a reduced frequency. The processor 1402 may have several levels of sleep states, which may be referred to as numbered states, starting with the D1 state and incrementing to D2, D3, D4, and so on. The different levels of sleep states may provide deeper levels of power savings from additional portions of the processor 1402 that may be powered off or other additional features of the processor 1402 that may be modified for lower power consumption. The sleep state may be entered after the processor 1402 leaves the awake state. In other words, the processor 1402 may execute instructions only when in the awake state.

[0147] Thus, in order to achieve the goal of efficient power management, the processor hardware and software executed on the processor 1402 can participate in various power saving decisions. These decisions may include stopping execution, clock modulation, clock throttling, or entering a dormant state. The dormant state can be implemented, for example, at the thread level or the core level. For the end user of the mobile computing platform including the processor 1402, the effect of power management may have some negative impact on usability and user experience. As expected, different dormancy levels of the processor may be associated with different types of delays, which may be manifested as a perceived slowdown during the operation of the mobile computing platform. In many cases, the extremely short or intermittent dormancy period generated by the power management decision on the processor 1402 may not cause a perceptible change in the operation of the mobile computing platform. However, this power management decision involving imperceptible changes in the dormancy of the processor 1402 may have limited impact on the actual power consumed by the processor 1402 and the mobile computing platform. As the power management decisions made in hardware or software become more aggressive in order to save more power, the adverse impact on the end user may increase.

[0148] Thus, a mobile computing platform including the processor 1402 may use the above-described different types of sleep states to reduce power without affecting the responsiveness and perceived operation of the mobile computing platform as experienced by an end user. Specifically, the processor 1402 may be developed using various adjustments, tuning, and testing in different use cases and contextual scenarios. Some examples of undesirable delays caused by power management decisions include wake-up time from a sleep state and interrupt service delays when employing a sleep state or other power saving measures, particularly when such interrupts involve end-user processing tasks (e.g., streaming of multimedia data).

[0149] In order to provide a desirable, responsive power management algorithm, the processor 1402 may include a trace function provided by the trace unit 1506 to accurately understand how the processor 1402 handles power management code or power management events in various operating contexts. For example, when a set of instructions including power management commands executed by the core 1412 is observed to produce unexpected results, a power management trace package may be provided to help understand which power management effects are a direct result of the power management commands and which power management effects are an indirect result of the power management commands, for example, due to power management decisions made by the power control unit 1508 (or other power management logic blocks) implemented in the processor 1402. In another example, power management events may be generated autonomously by hardware. Power management events generated autonomously by hardware may affect the execution of code.

[0150] In a given embodiment, the processor 1402 may utilize a processor tracing system (PTS), which is a debugging feature that enables accurate and detailed activity trace exposure with triggering and filtering capabilities. Therefore, the tracing functionality implemented by the trace unit 1506 (which may include certain PTS features) can be applied to both functional debugging and performance debugging.

[0151] The trace functionality implemented by the trace unit 1506 may include a low-overhead execution tracking feature that uses dedicated hardware facilities to capture information about software execution on each hardware thread executing on the core 1412 so that the software can process the captured trace after execution is complete. The captured information may be collected in data packets at the trace unit 1506 included in the core 1412. Although for clarity of description, Fig.15 1402, it is understood that each core implemented in the processor 1402 may include trace functionality, e.g., using a respective trace unit, such as the trace unit 1506, for each core. In some embodiments, the trace unit 1506 may be implemented in the back end of the processor 1402. For example, the trace unit 1506 may be implemented with a retirement unit or retirement logic. Thus, completed and retired operations may generate packets that are traced with the trace unit 1506.

[0152] The trace unit 1506 can generate a series of different types of trace packets. As will be described in further detail, an implementation of the trace unit 1506 can provide trace packets that provide information about power management in the core 1412 and in the processor 1402. For example, the trace unit 1506 can generate trace packets that provide frequency ratios of different bus clocks and wake-up times from sleep states. The trace unit 1506 can generate trace packets that provide insight into the parameters and activities of the core 1412.

[0153] According to an embodiment of the present disclosure, processor core power event tracing may provide a power management trace package using trace unit 1506. According to an embodiment of the present disclosure, implementation of processor core power event tracing may provide the capability to be implemented as a logic block in a processor core (e.g., core 1412). According to an embodiment of the present disclosure, processor core power event tracing may provide additional visibility into how power decisions affect the execution of threads by exposing thread-level sleep state information as well as a limited amount of core-level sleep state information to debug complex responsiveness issues in power management.

[0154] According to an embodiment of the present disclosure, processor core power event tracing can provide several new trace packets for power management, which can track sleep state entry points (sleep states with requests), stop pipeline clocks for any reason, sleep state entry with resolved thread sleep states, sleep state exit with exit reasons, and the last and deepest core-level sleep states achieved. In some cases, packets may be generated at wakeup rather than at entry into a given core state, because core state transitions may occur while a given thread is asleep. In one embodiment, trace packets generated by trace unit 1506 for power management may include sleep state request packets, code execution stop packets, sleep state entry packets, sleep state exit packets, timestamp packets, and processor frequency packets. Trace packets generated by trace unit 1506 for power management can be activated and generated independently of other trace packets generated by trace unit 1506, and can achieve improved visibility of extremely low bandwidth and performance impacts. For example, trace packets for power management can enable debugging of some complex power management decisions made by the power control unit 1508. In addition to the power management trace packets, according to an embodiment of the present disclosure, the processor core power event tracing can also provide a trace configuration register 1514 for activating the trace packets. The trace configuration register 1514 may include one or more separate bits for activating the generation of sleep state request packets, code execution stop packets, sleep state entry packets, and sleep state exit packets independently of other trace packets generated by the trace unit 1506.

[0155] According to an embodiment of the present disclosure, when the core 1412 is in an awake state (also referred to as an operating state), a dormant state request packet may indicate that the core 1412 has received a power management request for a specific dormant state. For example, the power management request may include a software instruction received by the processor 1402 or a request generated by a component of the processor 1402. The component may include a component that has received an input-output access, or an external assertion through a pin in the processor 1402. The request generated by the component of the processor 1402 may include a hardware signal. The dormant state request packet may include an indication of a specific dormant state. In certain embodiments, a dormant state request packet may be generated each time a specific instruction is received (e.g., received by the front end 1504) and the instruction is executed to enter the requested dormant state. In a specific embodiment, a dormant state request packet (DRSP) may be referred to as a DSRP trace packet and may include hint information and extended information. Hint information in the DSRP trace packet may provide information about a dormant state request command associated with the DSRP trace packet. The extended information may provide additional information, such as additional information about the context of the core 1412 .

[0156] According to an embodiment of the present disclosure, a code execution stop packet may indicate that the core 1412 has stopped the execution of code, for example at the front end 1504. A code execution stop packet may be generated each time the processor clock stops. The processor clock may stop each time, for example, the clock frequency changes. When the core 1412 resumes the execution of the code and a core to bus frequency ratio trace packet is generated, the code execution stop packet may be associated with a subsequent event. The code execution stop packet may include an indication of the instruction pointer address of a processor instruction, which is the next instruction to be completed when the code execution stop packet is generated. In a specific embodiment, a code execution stop packet (code execution stop packet, CESP) may be referred to as a CESP trace packet, which may include an instruction pointer address. The instruction pointer address included in the CESP packet may be the address of the next processor instruction to be completed when the code execution is stopped when the CESP trace packet is generated.

[0157] According to an embodiment of the present disclosure, a dormant state entry packet may indicate that the core 1412 has entered a deeper dormant state from a current dormant state or from a wake-up state. The dormant state entry packet may be generated accordingly from all dormant states, except for the deepest dormant state. In a particular embodiment, a dormant state entry packet (DSEP) may be referred to as a DSEP trace packet. The dormant state entry source field in the DSEP trace packet may indicate whether the power state entry associated with the DSEP trace packet was initiated by hardware or software. The DSEP trace packet may also include dormant state information about threads in the core 1412 associated with the DSEP trace packet.

[0158] According to an embodiment of the present disclosure, a dormant state exit packet may indicate (or imply) that the core 1412 has returned to a wake-up state, and may indicate that the front end 1504 is able to resume operation and begin executing instructions. A dormant state exit packet may be generated accordingly from all dormant states. In a particular embodiment, a dormant state exit packet (DSXP) may be referred to as a DSXP trace packet. The DSXP trace packet may indicate the last dormant state of the core 1412 when the DSXP trace packet was generated, and the deepest dormant state of the core 1412 since the DSEP trace packet was generated. The DSXP trace packet may also include a wake-up reason for the core 1412 associated with the DSEP trace packet, such as a wake-up caused by an interrupt, storage to a monitored memory address, or other possible wake-up sources, such as wake-up by a power control unit 1508.

[0159] B. Processor trace trigger tracing

[0160] Most of the trace data captured during workload execution is not important for software debugging or performance optimization. In some cases, such as anomaly detection, 95% of the captured trace data is discarded. Embodiments of the present invention improve the efficiency of the tracing usage model by utilizing techniques to pause and resume trace operations based on runtime events detected during the execution of the workload. By providing the ability to capture only the duration of interest, efficiency is greatly improved and the impact on the performance of the workload is minimized. In addition, some embodiments include new data packages that can also be used for lightweight sampling of some trigger events. These embodiments improve tracing efficiency and can attribute performance monitoring events to software execution with negligible impact on the performance of the workload.

[0161] Specifically, these implementations associate performance monitoring counters and debug breakpoint registers with processor trace logic. According to these embodiments, triggers and actions controlled by software or firmware are defined. For example, a trigger may be configured with respect to a performance monitoring counter increment or counter value, an overflow condition, or a breakpoint match. In addition, trigger actions may be configured, such as the generation of a specific processor trace packet (referred to as a "TRIG" packet) containing relevant information and / or starting or stopping a trace.

[0162] Fig.16 A processor trace circuit is illustrated according to one embodiment, the circuit including a trigger unit 1620 on which various trigger inputs and corresponding actions can be configured. In one implementation, each logical processor or core is associated with a plurality of such trigger units 1620. The presence of trigger unit capabilities, including the number of trigger units 1620, and supported inputs and actions, can be enumerated by software (e.g., using the CPUID instruction on some architectures).

[0163] In one embodiment, each trigger unit 1620 includes or is associated with a configuration (CFG) model specific register (MSR) 1660, which can be programmed with a value to indicate a trigger input and a corresponding trigger action. The trigger input is specified by a trigger input selection bit 1622, and the corresponding trigger action is indicated using a trigger action bit 1623 (e.g., configured as a bitmap in one embodiment).

[0164] Embodiments of the present invention integrate performance counters 1615 and / or debug registers 1605 into processor trace functionality. For example, performance counters 1615 are configured to route event message 1666 signals to trigger unit 1620 to indicate the occurrence of a performance monitoring event, such as reaching a specified counter threshold. In one embodiment, each performance monitoring counter 1615 is configured via a corresponding performance monitoring configuration register 1616, which includes one or more fields that specify the configuration of the performance monitoring counter 1615 (e.g., indicating conditions under which a trigger signal should be generated). An enable bit 1617 in a field of each configuration register 1616 can be set to configure the corresponding performance monitoring counter 1615 to participate in processor trace as described herein.

[0165] According to an embodiment of the present invention, a set of debug registers 1605 is also configured to generate trigger event messages 1667, which may include commands 1668 as described below. The set of debug registers 1605 controls the debug operation of the processor and can be written and read using a variant of the move (MOV) instruction (i.e., move to / move from debug register instructions). The debug address registers DR0-DR3 each store a 32-bit linear address of a debug breakpoint (e.g., the address of an instruction or data object that is the focus of the debug process). The contents of the debug control register DR7 further specify the breakpoint conditions. In one embodiment, a new set of enable bits is included in the debug control register DR7, one for each of the debug address registers DR0-DR3, for enabling or disabling trigger messages 1667 and / or commands 1668 in response to certain address matches. For example, when enabled, the debug address register generates a trigger message 1667 and / or command 1668 in response to an address match (e.g., when the current address matches the breakpoint address).

[0166] In some implementations, the microcode handler 1610 may be notified / initialized in response to a debug register match and may perform filtering based on the processor trace enable bits EN0-EN3. For example, in response to a breakpoint address match in one of the debug registers DR0-DR3, the microcode handler 1610 may check the corresponding enable bits EN0-EN3, respectively, to determine whether to send a debug register match trigger signal 1667 and / or a corresponding command 1668 to the trigger unit 1620.

[0167] In one embodiment, command 1668 includes suspend trace and resume trace commands to suspend or resume trace operations based on the detected breakpoint match. In response to message 1667 and / or command 1668, trigger unit 1620 sends a message to the processor trace circuit, including trace data associated with message 1667 and / or an indication of a command to suspend or resume trace operations. In one embodiment, trigger unit 1620 sends a new processor trace TRIG packet 1630 to hardware buffer 1642 of processor trace circuit 1640 for processing by the processor trace circuit.

[0168] In one embodiment, when a triggering event occurs (e.g., based on a triggering of a performance monitoring event), execution unit 1625 provides IP attribute information 1660 to trigger unit 1620, which associates IP attribute information 1660 with the corresponding event. For example, if event 1666 indicates that a performance monitoring counter threshold has been reached, trigger unit 1620 may associate this event 1666 with a specific functional unit, IP block, or subsystem specified by IP attribute information 1660 (e.g., such as a specific core 202A-N, execution unit integrated memory controller unit 214, dedicated logic 208, interconnect controller 216, etc.).

[0169] In one embodiment, the trigger unit 1620 may include the IP attribute information 1660 (or a portion thereof) in one or more TRIG packets 1630 communicated to the processor trace circuit 1640, which buffers / stores the corresponding trace data in a hardware buffer 1642 (or other storage structure, such as cache memory). The processor trace circuit 1640 may then store the trace data to the memory 1512 via the MMU 1510, where it may be accessed by the application. For example, a processor trace decoder may be implemented that parses the trace data (including the IP attribute associations) to link the trigger event to a code sequence in the running workload.

[0170] Fig.17 Additional details of trigger cells 1720A-B associated with a particular logical processor 1701 are shown, which may be a core, a portion of a core, or multiple cores, depending on the configuration. Each trigger cell 1720A-B includes a configuration MSR 1760A-B for storing a set of trigger input selection bits 1722A-B and a trigger action bitmap 1723A-B, respectively.

[0171] In this specific example, the trigger input selection bits 1722A-B include: a 7-bit PMC field, used to indicate one or more performance monitoring counters / events; a 7-bit PMC overflow field, used to indicate one or more counter overflow values; and a 4-bit debug register match field, used to indicate the debug register that generated the trigger event.

[0172] In one embodiment, when the conditions indicated by one or more of the trigger input selection bits 1722A-B are met, the corresponding trigger unit 1720A-B performs the trigger action indicated by the trigger action bitmap 1723A-B. In the illustrated embodiment, each trigger action bitmap 1723A-B includes: an enable bit (TRIG_EN) to indicate whether any action is enabled; an IP attribute enable bit (IPA_EN) to indicate whether the IP attribute is enabled for the corresponding trigger event; a pause bit to indicate whether the trace should be paused; and a resume bit to indicate whether the trace should be resumed in response to the corresponding trigger event.

[0173] exist Fig.18 A method according to one embodiment of the present invention is illustrated in . The method may be implemented in the context of the architecture described above, but is not limited to any particular processor or system architecture.

[0174] At 1801 , a debug unit (eg, one or more of a set of debug registers) is configured to participate in a processor trace sequence, and at 1802 , a performance monitoring unit (eg, one or more performance monitoring counters) is configured to participate in a processor trace sequence.

[0175] At 1803, one or more trigger units are associated with the logical processor and are configured to indicate trigger inputs and actions. For example, a first set of fields may be set to indicate trigger inputs (including those from debug and performance monitoring units), and a second set of fields may be set to indicate corresponding actions to be taken.

[0176] At 1804, the workload is executed with processor trace enabled. If it is determined at 1805 that a debug or performance monitoring trigger event is detected, then at 1806, the corresponding trigger unit generates and sends a trigger packet to the processor trace unit. As previously described, if configured for IP attribute information, the IP attribute information is included in the trigger packet. At 1807, the processor trace unit compiles trace data, including data received in response to the debug and / or performance monitoring trigger event, and copies the trace data to a memory. When it is determined at 1810 that the trace is complete, the process ends.

[0177] There is currently no solution that allows performance monitoring events and debug match events to control processor traces. To achieve the same functionality, a software driver must get interrupts on these events and manage the trace. Interrupting the workload can cause significant performance degradation of the workload. In addition, existing workload profiling methods consume a large number of workload cycles, limiting the sampling frequency to a lower level. Processor trace provides a hardware solution that improves the efficiency of the trace operation and provides a very low overhead sampling method.

[0178] Embodiments of the present invention allow for efficient use of processor trace hardware features, significantly reducing the time and effort required for debugging and performance tuning workloads. These embodiments are particularly useful, for example, for anomaly detection (e.g., short-term performance slowdowns), since performance monitoring and processor traces themselves have limitations.

[0179] Example

[0180] The following are example implementations of different embodiments of the invention.

[0181] Example 1. A processor comprising: a plurality of processing cores configurable as a plurality of logical processors; a processor trace circuit to perform trace operations to capture and process information related to program code executed by one or more of the logical processors; a debug unit to perform debug operations and collect debug data related to the execution of the program code; a performance monitoring unit (PMU) including a plurality of counter registers, the PMU collecting performance data related to the execution of the program code; and a plurality of trigger units, each trigger unit being associated with a logical processor of the plurality of logical processors and configured to communicate trigger event data to the processor trace circuit in response to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register.

[0182] Example 2. The processor of Example 1, wherein the configuration bits include: a plurality of trigger input selection bits for indicating a trigger event for which a trigger action is to be performed; and a plurality of trigger action bits for indicating an action to be performed in response to the corresponding trigger event.

[0183] Example 3. The processor of Example 1 or 2, wherein the trigger unit associates attribute information indicating a specific intellectual property (IP) block, a functional unit, or a group of functional units with a specific type of trigger event.

[0184] Example 4. The processor of any one of Examples 1-3, wherein the trigger unit generates a trigger packet including an indication of at least one trigger event and the attribute information when applicable, and the trigger unit sends the trigger packet to the processor trace circuit.

[0185] Example 5. The processor of any one of Examples 1-4, wherein upon receiving a first trigger event, the trigger unit sends a message indicating a trace suspend action or a trace resume action to the processor trace circuit based on a value of one or more of the plurality of trigger action bits, wherein the processor trace circuit suspends or resumes the trace operation in response.

[0186] Example 6. A processor as described in any one of Examples 1-5, wherein the debug unit further comprises: a plurality of debug registers, each debug register storing an address associated with a debug operation; and a debug control register for storing a plurality of bit values, the plurality of bit values ​​indicating: in response to a result of an address comparison with the address associated with the debug operation, which debug registers are to cause a trigger event to be sent to the trigger unit.

[0187] Example 7. The processor of any of Examples 1-6, wherein, responsive to the plurality of bit values, a microcode handler determines whether the trigger event is to be sent to the trigger unit.

[0188] Example 8. The processor of any one of Examples 1-7 further comprises: a plurality of PMU configuration registers, each PMU configuration register being associated with a counter register of the plurality of counter registers and configured to store a bit value to indicate whether a performance monitoring event associated with the corresponding counter register is to cause a trigger event to be sent to the trigger unit.

[0189] Example 9. A method, comprising: indicating a plurality of logical processors; performing, by a processor trace circuit, a trace operation to capture and process information related to program code executed by one or more of the logical processors; performing, by a debug unit, a debug operation including collecting debug data related to the execution of the program code; collecting, by a performance monitoring unit (PMU) including a plurality of counter registers, performance data related to the execution of the program code; and communicating, by a trigger unit of a plurality of trigger units, trigger event data to the processor trace circuit in response to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register.

[0190] Example 10. The method of Example 9, wherein the configuration bits include: a plurality of trigger input selection bits for indicating a trigger event for which a trigger action is to be performed; and a plurality of trigger action bits for indicating an action to be performed in response to the corresponding trigger event.

[0191] Example 11. The method of Example 9 or 10 further includes: associating, by the trigger unit, attribute information indicating a specific intellectual property (IP) block, a functional unit, or a group of functional units with a specific type of trigger event.

[0192] Example 12. The method of any one of Examples 9-11 further comprises: generating, by the trigger unit, a trigger packet including an indication of at least one trigger event and the attribute information when applicable, the trigger unit sending the trigger packet to the processor trace circuit.

[0193] Example 13. The method of any of Examples 9-12, wherein upon receiving the first trigger event, the trigger unit sends a message indicating a trace suspend action or a trace resume action to the processor trace circuit based on the value of one or more of the plurality of trigger action bits, wherein the processor trace circuit suspends or resumes the trace operation in response.

[0194] Example 14. The method as described in any one of Examples 9-13 further includes: storing multiple addresses associated with debug operations in multiple debug registers; and storing multiple bit values ​​in a debug control register, the multiple bit values ​​indicating: in response to the result of the address comparison with the address associated with the debug operation, which debug registers of the multiple debug registers are to cause the trigger event to be sent to the trigger unit.

[0195] Example 15. The method of any of Examples 9-14, wherein, in response to the plurality of bit values, a microcode handler determines whether the trigger event is to be sent to the trigger unit.

[0196] Example 16. The method of any of Examples 9-15, further comprising storing a bit value to indicate whether a performance monitoring event associated with a corresponding counter register is to cause a trigger event to be sent to the trigger unit.

[0197] Example 17. A machine-readable medium having program code stored thereon, the program code, when executed by a machine, causing the machine to perform operations, the operations comprising: indicating a plurality of logical processors; performing, by a processor trace circuit, trace operations to capture and process information related to program code executed by one or more of the logical processors; performing, by a debug unit, debug operations including collecting debug data related to execution of the program code; collecting, by a performance monitoring unit (PMU) including a plurality of counter registers, performance data related to execution of the program code; and communicating, by a trigger unit of a plurality of trigger units, trigger event data to the processor trace circuit in response to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register.

[0198] Example 18. The machine-readable medium of Example 17, wherein the configuration bits include: a plurality of trigger input selection bits for indicating a trigger event for which a trigger action is to be performed; and a plurality of trigger action bits for indicating an action to be performed in response to the corresponding trigger event.

[0199] Example 19. The machine-readable medium of Example 17 or 18 further comprises: the trigger unit associating attribute information indicating a specific intellectual property (IP) block, a functional unit, or a group of functional units with a specific type of trigger event.

[0200] Example 20. The machine-readable medium of any one of Examples 17-19, further comprising: generating, by the trigger unit, a trigger packet including an indication of at least one trigger event and, if applicable, the attribute information, the trigger unit sending the trigger packet to the processor trace circuit.

[0201] Embodiments of the present invention may include various steps, which have been described above. These steps may be embodied in machine executable instructions, which may be used to cause a general or special purpose processor to perform these steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing these steps, or by any combination of programmed computer components and custom hardware components.

[0202] As described herein, instructions may refer to hardware such as an application specific integrated circuit (ASIC) configured to perform certain operations or have predetermined functions, or a specific configuration of software instructions stored in a memory embodied in a non-transitory computer-readable medium. Thus, the techniques shown in the accompanying drawings can be implemented using code and data stored and executed on one or more electronic devices (e.g., terminal stations, network elements, etc.). Such electronic devices use computer machine readable media to store and communicate (internally and / or with other electronic devices through a network) code and data, wherein the computer machine readable medium is, for example, a non-transitory computer machine readable storage medium (e.g., a disk; an optical disk; a random access memory; a read-only memory; a flash memory device; a phase change memory) and a transient computer machine readable communication medium (e.g., an electrical, optical, acoustic or other form of propagation signal - such as a carrier wave, an infrared signal, a digital signal, etc.). In addition, such electronic devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices (non-transitory machine readable storage media), user input / output devices (e.g., a keyboard, a touch screen and / or a display), and a network connection. The coupling of the group of processors and other components is usually through one or more buses and bridges (also referred to as bus controllers). The storage device and the signal carrying the network traffic represent one or more machine-readable storage media and machine-readable communication media, respectively. Thus, the storage device of a given electronic device usually stores code and / or data to be executed on the group of one or more processors of the electronic device. Of course, one or more parts of the embodiments of the present invention can be implemented using different combinations of software, firmware and / or hardware. Herein, various places are described in detail, and for the purpose of illustration, many specific details are recorded in order to provide a thorough understanding of the present invention. However, it will be clear to those skilled in the art that the present invention can be implemented without some of these specific details. In some cases, the known structures and functions are not described in detail to avoid blurring the subject matter of the present invention. Therefore, the scope and spirit of the present invention should be judged according to the appended claims.

Claims

1. A processor, comprising: Multiple processing cores that can be configured as multiple logical processors; processor trace circuitry to perform trace operations to capture and process information related to program code executed by one or more of the logical processors; a debugging unit to perform debugging operations and collect debugging data related to the execution of the program code; a performance monitoring unit (PMU) comprising a plurality of counter registers, the PMU collecting performance data related to execution of the program code; as well as a plurality of trigger units, each trigger unit being associated with a logical processor of the plurality of logical processors and configured to communicate trigger event data to the processor trace circuit in response to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register.

2. The processor of claim 1, wherein: The configuration bits include: a plurality of trigger input selection bits for indicating a trigger event for which a trigger action is to be performed; and a plurality of trigger action bits for indicating an action to be performed in response to a corresponding trigger event.

3. The processor according to claim 1 or 2, wherein: The trigger unit associates attribute information indicative of a specific intellectual property (IP) block, a functional unit, or a group of functional units with a specific type of trigger event.

4. The processor of claim 3, wherein: The trigger unit generates a trigger packet including an indication of at least one trigger event and, if applicable, the attribute information, the trigger unit sending the trigger packet to the processor trace circuit.

5. A processor as claimed in any one of claims 2 to 4, wherein: Upon receiving a first trigger event, the trigger unit sends a message indicating a trace suspend action or a trace resume action to the processor trace circuit based on the value of one or more of the plurality of trigger action bits, wherein the processor trace circuit suspends or resumes the trace operation in response.

6. The processor according to any one of claims 1 to 5, wherein: The debugging unit also includes: a plurality of debug registers, each debug register storing an address associated with a debug operation; and A debug control register is used to store a plurality of bit values ​​indicating which debug registers are to cause a trigger event to be sent to the trigger unit in response to a result of an address comparison with an address associated with a debug operation.

7. The processor of claim 6, wherein: Responsive to the plurality of bit values, a microcode handler determines whether the trigger event is to be sent to the trigger unit.

8. The processor of any one of claims 1 to 7, further comprising: A plurality of PMU configuration registers, each PMU configuration register being associated with a counter register of the plurality of counter registers and configured to store a bit value indicating whether a performance monitoring event associated with the corresponding counter register is to cause a trigger event to be sent to the trigger unit.

9. A method comprising: performing trace operations by processor trace circuitry to capture and process information related to program code executed by one or more logical processors; performing debugging operations by a debugging unit, including collecting debugging data related to the execution of the program code; collecting performance data related to execution of the program code by a performance monitoring unit (PMU) including a plurality of counter registers; and Trigger event data is communicated to the processor trace circuit by a trigger unit of a plurality of trigger units in response to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register.

10. The method of claim 9, wherein: The configuration bits include: a plurality of trigger input selection bits for indicating a trigger event for which a trigger action is to be performed; and a plurality of trigger action bits for indicating an action to be performed in response to a corresponding trigger event.

11. The method according to claim 9 or 10, further comprising: Attribute information indicative of a specific intellectual property (IP) block, a functional unit, or a group of functional units is associated by the trigger unit with a specific type of trigger event.

12. The method of claim 11, further comprising: A trigger packet is generated by the trigger unit, the trigger packet including an indication of at least one trigger event and, if applicable, the attribute information, the trigger unit sending the trigger packet to the processor trace circuit.

13. The method according to any one of claims 10 to 12, wherein: Upon receiving a first trigger event, the trigger unit sends a message indicating a trace suspend action or a trace resume action to the processor trace circuit based on the value of one or more of the plurality of trigger action bits, wherein the processor trace circuit suspends or resumes the trace operation in response.

14. The method of any one of claims 9 to 13, further comprising: storing a plurality of addresses associated with debug operations in a plurality of debug registers; and A plurality of bit values ​​are stored in the debug control register, the plurality of bit values ​​indicating which debug registers of the plurality of debug registers are to cause a trigger event to be sent to the trigger unit in response to a result of an address comparison with an address associated with a debug operation.

15. The method of claim 14, wherein: Responsive to the plurality of bit values, a microcode handler determines whether the trigger event is to be sent to the trigger unit.

16. The method of claim 9, further comprising: A bit value is stored to indicate whether a performance monitoring event associated with a corresponding counter register is to cause a trigger event to be sent to the trigger unit.

17. A machine-readable medium having a program code stored thereon, wherein when the program code is executed by a machine, the machine performs an operation, the operation comprising: Indicates multiple logical processors; performing trace operations by processor trace circuitry to capture and process information related to program code executed by one or more of the logical processors; performing debugging operations by a debugging unit, including collecting debugging data related to the execution of the program code; collecting performance data related to execution of the program code by a performance monitoring unit (PMU) including a plurality of counter registers; and Trigger event data is communicated to the processor trace circuit by a trigger unit of a plurality of trigger units in response to a trigger event received from at least one of the debug unit and the PMU according to a value of a configuration bit in a corresponding trigger unit configuration register.

18. The machine-readable medium of claim 17, wherein: The configuration bits include: a plurality of trigger input selection bits for indicating a trigger event for which a trigger action is to be performed; and a plurality of trigger action bits for indicating an action to be performed in response to a corresponding trigger event.

19. The machine-readable medium of claim 17, further comprising: Attribute information indicative of a specific intellectual property (IP) block, a functional unit, or a group of functional units is associated by the trigger unit with a specific type of trigger event.

20. The machine-readable medium of claim 19, further comprising: A trigger packet is generated by the trigger unit, the trigger packet including an indication of at least one trigger event and, if applicable, the attribute information, the trigger unit sending the trigger packet to the processor trace circuit.

Images