Application programming interface for fine-grained low-latency decompression within processor core

Abstract

The invention relates to an application programming interface for fine-grained low-latency decompression within a processor core. Methods and apparatus relating to an application programming interface (API) for fine-grained low-latency decompression within a processor core are described. In an embodiment, a decompression application programming interface (API) receives an input handle of a data object. The data object includes compressed data and metadata. A decompression engine (DE) circuit decompresses the compressed data to generate uncompressed data. The DE circuitry decompresses the compressed data in response to a call of the decompression instruction by the decompression API. The metadata comprises a first operation object used for indicating the position of the compressed data; the second operation object is used for indicating the size of the compressed data; a third operation object for indicating a position to which decompressed data of the DE circuit is to be stored; and the fourth operation object is used for indicating the size of the decompressed data. Other embodiments are also disclosed and claimed.

Description

[0001] Description of the case

[0002] This application is a divisional application of the invention patent application with application date of November 22, 2021, application number 202111387205.6, and titled "Application programming interface for fine-grained low-latency decompression within processor core". Technical Field

[0003] The present disclosure relates generally to the field of electronics. More specifically, some embodiments relate to an application programming interface (API) for fine-grained low-latency decompression within a processor core. Background Art

[0004] Generally speaking, dynamic random access memory (DRAM) and / or interconnect bandwidth limitations can be the primary performance bottleneck for current central processing unit (CPU) cores. These bandwidth limitations result in latency in data transfers to and from the CPU core. Therefore, reducing or eliminating DRAM and / or interconnect bandwidth limitations can significantly improve CPU performance. Summary of the Invention

[0005] According to one embodiment of the present disclosure, a device for providing an application programming interface (API) for fine-grained low-latency decompression is provided, the device comprising: a memory for storing a decompression application programming interface (API), the decompression API for receiving an input handle of a data object, wherein the data object comprises compressed data and metadata; and a decompression engine (DE) circuit for decompressing the compressed data to generate uncompressed data, the DE circuit for decompressing the compressed data in response to a call to a decompression instruction by the decompression API, wherein the metadata comprises: a first operation object for indicating a location of the compressed data; a second operation object for indicating a size of the compressed data; a third operation object for indicating a location where the decompressed data of the DE circuit is to be stored; and a fourth operation object for indicating the size of the decompressed data.

[0006] According to another embodiment of the present disclosure, a machine-readable medium is provided, including codes, which, when executed, enable a machine to perform the above operations.

[0007] According to another embodiment of the present disclosure, a device is provided, including means for performing the above operations. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order that the features of the embodiments described herein may be understood in detail, a more particular description of the embodiments may be made by reference to embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the drawings illustrate only typical embodiments and are therefore not to be considered limiting of their scope.

[0009] Figure 1 Illustrated is a block diagram of a processor having private cache levels and a shared last level cache that may be utilized in some embodiments.

[0010] Figure 2 Sample operands of a decompression instruction are illustrated according to one embodiment.

[0011] Figure 3 Two sample decode operations of a decompressed instruction are illustrated according to one embodiment.

[0012] Figure 4 A high-level diagram of various components of a processor core is illustrated according to an embodiment.

[0013] Figure 5 A flow chart illustrating a method of providing decompression closer to the processor core is provided according to an embodiment.

[0014] Figure 6 Sample evaluation results are shown according to one embodiment.

[0015] Figure 7A is a block diagram illustrating an exemplary instruction format according to an embodiment.

[0016] Figure 7B is a block diagram illustrating the fields of an instruction format that make up a complete opcode field, according to one embodiment.

[0017] Figure 7C is a block diagram illustrating the fields of an instruction format that make up a register index field, according to one embodiment.

[0018] Figure 7D is a block diagram illustrating the fields of an instruction format that make up an enhanced operation field, according to one embodiment.

[0019] Figure 8 is a block diagram of a register architecture according to one embodiment.

[0020] Figure 9A is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline, according to an embodiment.

[0021] Figure 9Bis a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue / execution architecture core to be included in a processor, according to an embodiment.

[0022] Figure 10 A block diagram of an SOC (System on Chip) package is illustrated according to an embodiment.

[0023] Figure 11 is a block diagram of a processing system according to one embodiment.

[0024] Figure 12 is a block diagram of an embodiment of a processor having one or more processor cores in accordance with some embodiments.

[0025] Figure 13 is a block diagram of a graphics processor according to one embodiment. DETAILED DESCRIPTION

[0026] In the following description, many specific details are set forth to provide a thorough understanding of the various embodiments. However, the various embodiments may be implemented without these specific details. In other cases, well-known processes, components, and circuits are not described in detail so as not to obscure the particular embodiments. In addition, various means may be used to perform various aspects of the embodiments, such as integrated semiconductor circuits ("hardware"), computer-readable instructions organized into one or more programs ("software"), or some combination of hardware and software. For purposes of this disclosure, reference to "logic" shall refer to hardware, software, firmware, or some combination thereof.

[0027] As mentioned above, the performance of current processor or central processing unit (CPU) cores is significantly limited by dynamic random access memory (DRAM) and / or interconnect bandwidth. To expand DRAM or interconnect bandwidth, an effective approach is to use compression and decompression to reduce the amount of data transferred to and from the core. However, even when using accelerators to speed up compression / decompression, the large compression / decompression latency limits the effectiveness of this solution.

[0028] To this end, some embodiments provide techniques related to an application programming interface (API) for fine-grained, low-latency decompression within a processor core. In one embodiment, the decompression API receives an input handle to a data object. The data object includes compressed data and metadata. In one embodiment, the metadata remains uncompressed to assist in identifying compressed portions for decompression. A decompression engine (DE) circuit decompresses the compressed data to generate uncompressed data. The DE circuit decompresses the compressed data in response to a call to a decompression instruction (or DISA) from the decompression API.

[0029] In addition, at least one embodiment provides instructions and / or microarchitecture support for decompression on a processor or CPU core. Such ISA extensions may also be referred to herein as decompression ISAs or "DISAs." One or more embodiments provide a hardware-software collaborative solution that provides a low-latency decompression solution at the hardware level for an end-to-end compression / decompression solution. In at least one embodiment, the utilized instruction(s) follow the EVEX format (e.g., reference Figures 7A-7C However, embodiments are not limited to the EVEX format, and any instruction format may be used to implement various embodiments.

[0030] Various embodiments provide bandwidth advantages to and from the processor core, thereby reducing pressure not only on DRAM, but also on the interconnects coupling various components of the processor (including one or more cores, memory, etc.). One embodiment includes a decompression accelerator and architecturally enables the decompression accelerator in the level 2 (L2) cache (also interchangeably referred to as mid-level cache or "MLC") of the processor core. At least one embodiment signals the processor core after each cache line (e.g., 64B, where "B" refers to one or more bytes) of data has been decompressed. This is in contrast to some approaches that may wait for a complete block of data (e.g., a page or 4KB) to be decompressed before allowing the decompressed data to be consumed or accessed, thereby incurring a significant latency penalty.

[0031] In addition, one or more embodiments also allow speculative decompression of data, allowing a large depth of out-of-order core to absorb expensive decompression latency, for example, by allowing data to be decompressed out of order rather than sequentially. Generally speaking, to improve performance, some processors utilize speculative processing (sometimes also referred to as out-of-order (OOO) processors), which executes programs in parallel and faster than a sequential process would follow. The speculative processing may or may not ultimately be correct. When it is correct, the execution time of the program will be shorter than when non-speculative processing is used, thereby improving performance and reducing latency. In addition, in one embodiment, a new instruction in the ISA is utilized to enable the core to communicate with the decompression accelerator.

[0032] In contrast, some implementations can rely on compression / decompression performed entirely in software to increase effective memory capacity. However, pure software decompression is slow and expensive. In addition, hardware accelerators can be used to compress and decompress data stored far away from the core. However, hardware decompression accelerators operate on large blocks of data. Generally speaking, this is done to take into account the large distance between these accelerators and the core in order to spread the large communication latency. For applications that need to work with many small objects, this coarse-grained decompression is not very useful or efficient.

[0033] On the other hand, the decompression accelerator proposed as part of this disclosure is located at or near the core's L2 cache (i.e., closer to the core). This enables fast communication between the core and the accelerator via dedicated instructions. The accelerator can thus be designed to signal / inform the core when decompression of each cache line (e.g., every 64B) is complete, without having to wait for the rest of the block to be decompressed. The accelerator can signal the core using a dedicated signal, a dedicated signaling bus, a packet with completion information, or by changing a status bit in a designated register or location in a cache (e.g., an L1 cache or an L2 cache). This signaling can also convey the address / location of the decompressed cache line in the (e.g., L2) cache, or include the decompressed data. Thus, the core can advance progress (enable ILP) while decompression continues to decompress subsequent cache lines of a larger block. Furthermore, the decompression accelerator can be speculatively called. By speculatively calling the accelerator, the latency of decompression can be hidden by the processor's deep out-of-order window. These two approaches enable one or more embodiments to go beyond the current state of the art, allowing for fine-grained decompression very close to the core(s).

[0034] Additionally, some embodiments may be applied to a computing system including one or more processors (eg, where the one or more processors may include one or more processor cores), such as with reference to FIG. Figure 1 and those discussed in the subsequent figures, including, for example, desktop computers, workstations, computer servers, server blades, or mobile computing devices. Mobile computing devices may include smartphones, tablet devices, UMPCs (Ultra Mobile Personal Computers), laptops, Ultrabooks, TM Computing devices, wearable devices (e.g., smart watches, smart rings, smart bracelets, or smart glasses), etc.

[0035] For example, Figure 1A block diagram of a processor 100 with private cache levels and a shared last-level cache that may be utilized in some embodiments is illustrated. As shown, each core has several private cache levels (e.g., including L1 and Level 2 (L2) cache levels (L2 cache may sometimes be referred to as Mid-Level Cache (MLC)), which may be kept coherent, and also has a shared last-level cache (LLC), which may be distributed among multiple cores. An on-chip network may facilitate communication between cores, L2 caches, and / or distributed LLCs. Caches may sometimes be represented by a dollar sign ($), such as Figure 1 Generally speaking, cache coherence is managed at the granularity of cache blocks or cache lines. In addition, Figure 1 As shown, a core may include an L1 cache, while an L2 cache may cross the boundary and be implemented as part of the core or external to the core (as indicated by the dashed box indicating optional placement of the L2 cache). Figure 1 Shown as being external to the core and shared among multiple processor cores.

[0036] Decompression logic circuitry / engine 102 may be provided in various locations within processor 100. In at least one embodiment, decompression logic 102 may be within a core, for example, adjacent to or near an L2 cache. However, embodiments are not limited thereto, and decompression logic 102 may instead be located outside the core, for example, coupled to an on-chip network, a distributed LLC, or between a core and an on-chip network / distributed LLC.

[0037] In one embodiment, the x86 ISA (written by The decompression logic 102 is a hardware accelerator that stores the compressed data in the L2 cache (or another cache like the LLC, depending on the implementation and / or the size of the data). In one embodiment, the decompression operation is performed speculatively and the processor / core continues to execute instructions that do not depend on the decompressed data, thereby hiding the latency of the decompression. Once the data requested by the core (e.g., one or more cache lines) is available in a decompressed state, the core can continue execution without waiting for the full decompression operation of all cache lines or (one or more) blocks of data to complete.

[0038] Thus, some embodiments allow a processor to scale up DRAM and / or interconnect bandwidth, independent of the DRAM and / or interconnect technology or vendor used, and provide overall performance gains to the processor by alleviating memory and / or interconnect bottlenecks. By effectively increasing DRAM and / or interconnect bandwidth (e.g., due to compression) and the proposed low-latency decompression, customers can help reduce data center TCO (total cost of ownership) for memory. Simulation results show, for example, up to 2x performance on bandwidth-sensitive cores representative of data center use case scenarios. To this end, some embodiments address memory bottlenecks that limit processor performance. Using data compression in a hardware-software collaborative manner, applications can achieve substantially lower memory bandwidth requirements.

[0039] To compress data, an application identifies its target data structure and compresses it using an available compression algorithm (e.g., DEFLATE). As discussed herein, "Deflate" or "DEFLATE" generally refers to a lossless data compression file format used in conjunction with compression encoding, for example, according to Lempel-Ziv-Storer-Szymanski (LZSS) and / or Huffman encoding. Compression can be performed in software or using a load shifting engine. Generally speaking, compression is performed on frequently used data to minimize memory bandwidth requirements. Reading frequently used data in compressed form effectively reduces memory bandwidth requirements. However, decompression latency now significantly impacts performance. In addition, server products are also limited by interconnect bandwidth, so according to some embodiments, it is important to transmit compressed data on the interconnect and perform low-latency decompression as close to the core as possible.

[0040] To achieve this, one embodiment uses a dedicated hardware accelerator (e.g., decompression logic 102) close to the core and performs low-latency decompression. Leveraging microarchitectural support in the core's pipeline and a dedicated decompression engine at the L2 cache, DISA enables fine-grained, cache-line-level access to decompressed data.

[0041] As discussed below, there are three separate processes within DISA:

[0042] 1. ISA Extensions—This section describes the instruction semantics of the hardware decompression engine, as well as the ISA extensions to access it in software.

[0043] 2. Software Support—This section describes how the compression and decompression steps can be included in the application code (eg, user space).

[0044] 3. Hardware / Microarchitectural Support - This section describes how the core pipeline is modified to handle decompression and how the final decompressed data is delivered to consumer instructions in the user program space. This section also describes the microarchitectural flow that enables decompression to be performed using additional hardware in the form of a decompression engine that implements the decompression functionality associated with the compression algorithm.

[0045] In this scenario, one purpose of compression is to provide bandwidth savings all the way to the core. This not only saves memory bandwidth, but also saves network / interface bandwidth.

[0046] ISA extensions

[0047] Figure 2 A sample operand 200 of a decompressed instruction is illustrated according to one embodiment. Figure 3 Two sample decoding operations of a decompression instruction are illustrated according to one embodiment. A special hardware decompression instruction is used, which will be referred to as DISA from this article on, i.e., Decompression ISA. Its semantics are described as follows:

[0048] A. It may have at least four fields—1. Source (compressed) data location 202 (e.g., virtual memory address); 2. Source data size 204 (the software API (application programming interface) that provides compression may also provide the compressed output size); 3. Destination 206 (decompressed) data location (e.g., virtual memory address); 4. Destination data size 208 (stored in any available logical temporary register).

[0049] B. It can have other variations, such as using a consumer bitmap. For example, when considering compression at a page-level granularity, then for a 4KB memory page and a 64-byte cache line size in the core, this bitmap can be 64 bits long, signaling / indicating which indexed cache lines are meaningful to the consumer instructions / code after decompression is complete. As an alternative or in addition to the bitmap, a bit mask can also be used to select cache lines for decompression and / or access. This approach has the potential to improve cache space management, minimize evictions, etc.

[0050] C. After being fetched and decoded by the processor's front end (e.g., front end 930 of FIG. 9 ), the DISA is divided into Figure 3 Two fused micro-operations (uops) are shown. The first fused uop 302 is a load operation that dispatches one or more loads for all cache lines containing compressed data to be decompressed. These load(s) access memory and are read from DRAM or main memory (e.g., Figure 101060) fetches the required cache line into the core cache. The second fused uop 304 is a store operation that acts as a macro store that signals the decompression engine 102 to start and perform decompression. Unlike traditional stores that go directly to memory / DRAM to bring the cache line to be written into the core's cache, some embodiments use a macro store "DISA store" that causes the decompression engine 102 to produce uncompressed data into the core's cache line, e.g., as shown in reference Figure 4 Further discussion. Figure 3 As shown, load uop 302 may receive operands 202 and 204 , while store uop 304 may receive operands 206 and 208 .

[0051] Furthermore, in at least one embodiment, a four-operand instruction may be decomposed into two or more instructions as needed for ease of execution.

[0052] Software Support

[0053] Initially, a decision is made (e.g., by a programmer, designer, and / or user) as to which data objects are large enough to benefit significantly from compression. Compressibility, or the compression ratio that can be achieved, may also be a factor influencing this decision. The liveness of the decompressed data, meaning whether it needs to be globally decompressed and stored, or whether it is a temporary variable that survives as long as the function containing the data is alive on the program stack, may be another design choice. One embodiment is independent and agnostic of these choices and simply operates on the decompressed target while adhering to the architectural semantics previously described. Additionally, one or more of the APIs discussed herein may be stored in any type of storage device, such as a reference to a memory device. Figure 1 and those discussed in the subsequent figures, including, for example, caches (e.g., L1 caches, L2 caches (e.g., Figure 4 L2 426), LLC, etc.).

[0054] One embodiment provides a public API that is imported into program code as a static library. It consists of compression functions that implement a given compression algorithm or algorithms (e.g., DEFLATE) and, given a byte of data of any size, compress it into a programmer-accessible object containing the compressed data and other metadata for later decompression. In one embodiment, the metadata remains uncompressed to assist in identifying the compressed portion for decompression. The following is an example that can serve as a design template for such an API and the corresponding calls in an application of interest:

[0055]

[0056] Here, "my_struct" is the type of the custom data structure in the example application that is the target of compression, and "COMPRESSED_DATA" is the defined compressed data structure / format that is recognized and used for subsequent decompression.

[0057] One embodiment provides a handle(s) (sometimes referred to as a pointer(s)) to the actual compressed data, as well as information about how much compressed data needs to be decompressed, which is held in a defined data structure. As described above, a bitmap and / or bitmask can be used to select specific cache lines for decompression and / or access.

[0058] Furthermore, when accessing the raw data belonging to user_data_array later in the program (for example, in a read-only manner), another API function can be used, as follows:

[0059] (my_struct*)decompress_user_data(COMPRESSED_DATA*);

[0060] / / The decompression ISA or DISA will be called within this function (and potentially cached to service multiple "structs" read from the same 4KB page).

[0061] This API decompression function corresponds to the DISA hardware counterpart. It takes as input the handle of the compressed data object obtained before using the software API function. But instead of decompressing it in hardware like some software-based compression routines, it can use the DISA hardware decompression instructions. Since the compressed data object also contains metadata related to the compression, it will provide the three main parameters required by the special ISA extension instructions, namely, the virtual address location of the compressed data, the original (uncompressed) size of the data required, and the compressed data size obtained after compression. The last parameter (argument) is the virtual address location of the decompressed data, which can be created locally by the programmer explicitly, or it can be created by the API function definition in the program space when calling this function.

[0062] Microarchitectural details

[0063] Figure 4 A high-level diagram of various components of processor core 400 is illustrated according to one embodiment. Figure 5 A flow chart of a method 500 for providing decompression closer to the processor core is shown according to one embodiment. In one or more embodiments, the operations of the method 500 may be performed by Figure 4 The system is executed by one or more hardware components of the system, as further discussed below.

[0064] refer to Figure 4 , the modified application code using the above API functions and working with compressed data in program space is executed on the processor core 400 with hardware support to provide pure hardware decompression and decoupled from both software and the operating system (OS). For illustration, it is assumed that the target uncompressed data can be loaded into DRAM or main memory (such as Figure 10 The application code is composed of one or more load instructions that read the decompressed data after it has been decompressed and stored in the core's cache (e.g., L2 cache, L1 cache, and / or LLC cache).

[0065] refer to Figure 4 and Figure 5 , operation 502 detects a DISA instruction (e.g., by core 408). As discussed above in the ISA extension section, the fetch and decode of a DISA instruction will generate two fused uops in the core's OOO (e.g., scheduled for execution by OOO scheduler 402)—one fused uop to load compressed data from DRAM into a re-order buffer (ROB) 404 in the cache(s), and another to store the decompressed data back into memory (cache / DRAM) for subsequent consumption. Operation 504 generates macroload and macrostore operations for the DISA instruction, and operation 506 sends the DISA instruction (or even a signal indicating a decompression request) to DE 102. Operations 504 and 506 may be performed by components of core 408, as discussed further herein. The following operations may be used to process the DISA macroload and DISA macrostore to implement decompression in hardware 406.

[0066] When the source of the DISA macro load, such as the compressed data memory location and compressed data memory size, is available, the DISA macro load is dispatched from the OOO scheduler 402. It can be dispatched normally from the core 408 to the uncore 410 and can be broken down into multiple loads (e.g., Load(1), Load(2), ..., Load(x) shown in ROB 404) during dispatch because the compressed data may span multiple cache lines, depending on the compressed data size. Since the OS is unaware of the compressed data format and it exists in program space, it brings the corresponding cache lines - such as any data will be brought from the physical page corresponding to the virtual memory location of the compressed data - into cache line blocks, which the core can then store and process.

[0067] DISA macro stores can be dispatched while DISA macro loads are retrieving data from memory. This timing of dispatch can provide bandwidth savings, thereby providing performance gains. DISA macro stores continue to be dispatched from the store buffer (SB) 412 to the uncore 410 when all sources for the DISA macro store, namely the memory address and decompressed size for storing the decompressed data, are available. After being dispatched from the SB 412, the DISA macro store 420 is captured / saved by the decompression engine (DE) or logic 102 until decompression is complete 414. Similar dispatched consumer loads 422 remain in the DE 102, as identified by their matching SB identifiers (IDs) 414.

[0068] like Figure 4 As shown, the decompression logic / engine 102 operates at the L2 cache ( 216 ) level and uses its cache lines as its temporary storage or staging area 424 . Figure 5 Operation 508 allocates space in a (e.g., L2) cache for decompression purposes. For example, DE 102 may retain a necessary number of cache lines in L2 cache 426 (e.g., depending on the size of the decompressed data) and prevent them from being accessed, modified, or evicted (e.g., by marking them as uncacheable) until the decompression logic / engine 102 completes decompression of the compressed data. Operation 510 (e.g., performed by DE logic 102 and / or a cache controller or other logic coupled to L2 cache 426) determines whether there is sufficient space for the decompressed data, and if eviction is required, operation 512 evicts one or more cache lines from the L2 cache (e.g., based on a Least Recently Used (LRU) algorithm or another algorithm). Otherwise, if eviction is not required, DE logic 102 performs decompression in an allocated scratch pad 424 in the L2 cache.

[0069] Once the decompression cache line load is complete, DE 102 matches the pending load(s) and provides write-back (WB) data in operation 516, for example, for storage in memory 428. One reason for using the L2 cache is that it is much larger than the L1, so space can be reserved within its capacity while supporting (one or more) standard, non-decompression logic / engine 102-related cache line management operations. It may also augment DISA operations to support multiple decompressions occurring simultaneously in the decompression engine 102. However, embodiments are not limited to using the L2 cache for these purposes, and other cache levels (e.g., L1 and / or LLC) may be used depending on the implementation.

[0070] Furthermore, all subsequent consumer loads 430 (e.g., in program order) that access the decompressed data region may be dispatched in the OOO scheduler 402 and Load Buffer (LB) 432 while the DISA macro stores have not yet completed and occupy entries in the store buffer (SB) 412. Memory disambiguation logic (not shown) present in the core blocks these requests from being dispatched to the uncore until the DISA macro stores complete and are written back 428. This blocking occurs because of the overlapping virtual address regions detected by the disambiguation between the DISA macro stores and these related loads 434. Other unrelated / younger loads (which may not depend on the decompressed data) will not be blocked and may proceed.

[0071] Additionally, a DISA macrostore, when its source is ready, updates its destination / write virtual address area in SB 412, which can be used by any younger load operations that rely on memory as described above. The DISA-SB entry continues to block younger loads until it receives a "ready" signal from the decompression logic / engine 102 (which has been assigned a connection to the SB). It then transfers the data to the L2 cache (because it is marked as uncacheable in the L1), and the decompression logic / engine 102 recognizes the DISA-dependent store request and sets its state variable (which tracks the DISA-SB-ID to isolate the active DISA) to initiate decompression. Using the decompression size, it calculates how many cache lines are needed to write back the decompressed data and evicts (e.g., using an LRU (least recently used) algorithm) the required number of cache lines to keep them dedicated to the output of the decompression logic / engine 102, as discussed with reference to operations 510 and 512. The L2 cache may also mark these as inaccessible to the core 408 , and the decompression logic / engine 102 may store indices (eg, set / way) of these cache line mappings.

[0072] As decompression logic / engine 102 begins decompression—which may take multiple cycles depending on the compression algorithm and the decompression level used—it issues an acknowledge signal to SB 412 to unlock the waiting loads by bypassing them in the disambiguation logic using the DISA SB ID as an exclusion condition. Thus, the younger consumer loads are unlocked to disambiguate and issued.

[0073] Additionally, consumer loads matching a DISA SB may carry the SB ID or be otherwise associated with it. In one embodiment, these consumer loads are marked as uncacheable in the L1 cache and go directly to the L2 cache without a L1 cache lookup. Decompression logic / engine 102 detects / traps these loads and provides them with a lookup in the MLC (using the source load address and the mapping of the decompressed address region to the reserved L2 cache line recorded by decompression logic / engine 102 when performing its reservation). The load then reads the decompressed data from the MLC. If the cache line has not yet been written, the load is blocked at this point. The writeback will only complete when decompression logic / engine 102 completes its process, writes back the data, and signals the load to proceed to its corresponding cache line. Eventually, decompression logic / engine 102 will complete its active DISA, and by then, all loads will have received the required data and will write back to their destination registers when sent back to the core. The decompression logic / engine 102 then finally signals back to the corresponding SB ID and writes its status back to done 428 .

[0074] When a DISA macro store becomes the head of an SB 412 and is able to retire after a write back, it becomes senior. It is eventually dispatched to the uncore 410 and its SB is deallocated. The decompression logic / engine 102 recognizes the store's seniority request and unreserve the reserved memory - making the corresponding cache line go from "private to decompression logic / engine 102" to "public to core". For speculatively executed decompression operations, operation 518 determines if the speculation was correct and if so, commits and makes the data visible in the L2 cache; otherwise, the allocated scratch pad in the L2 cache is released / invalidated. In addition, the DE logic 102 also decompresses the memory by sending data to DRAM or main memory (e.g., Figure 10 4060) issues (e.g., multiple) older stores to write the final compressed data back 428 to memory. In one embodiment, once the DISA instruction is committed in the ROB 404, an atomic store is performed to write the data back and free up the allocated space in the L2 cache. This delayed write back to memory is another optimization where the corresponding (one or more) younger loads can get the decompressed data directly without having to go all the way to the core 408. It acts as a bypass at the L2 for dependent loads. In one embodiment, if there is an error during decompression, the scratch pad 424 will be discarded and an OS fault can be issued to correct it. Furthermore, while the load and store operations triggered by DISA may appear as one atomic load and one atomic store, as described above, a series of load and store operations may be performed.

[0075] Performance Summary

[0076] Figure 6 Sample evaluation results are shown according to one embodiment. Figure 6 The evaluation data shown in is evaluated relative to a hypothetical next generation OOO architecture, for example, in a constrained memory bandwidth scenario. Two kernels were traced for the analysis, one mimicking a sample database running on a server. The other is a proxy for a compute-bound kernel. It can be seen that a DISA engine located next to the MLC (20 cycle communication latency) has the potential to provide a significant performance boost (over a 2x IPC (instructions per cycle) gain). In addition, the performance of a similarly constructed decompression accelerator located much further away (e.g., on a mesh interconnect) has a much higher startup latency. As might be expected, the performance gain from such a distant accelerator is significantly diminished. These results clearly demonstrate the potential advantages of reading compressed data over an interconnect and decompressing it using low latency techniques, as disclosed in one or more embodiments.

[0077] instruction set

[0078] An instruction set 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., an opcode) and the (one or more) operands and / or other (one or more) data fields (e.g., a mask) on which the operation is to be performed, etc. Some instruction formats are further decomposed by defining instruction templates (or subformats). For example, the instruction templates of a given instruction format may be defined as having different subsets of the fields of the instruction format (the included fields are generally in the same order, but at least some have different bit positions because there are fewer included fields) and / or as having given fields that are interpreted in different ways. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, expressed using a given one of the instruction templates of 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 that includes an opcode field to specify the opcode and an operand field to select the operand (source 1 / destination and source 2); and an appearance of this ADD instruction in an instruction stream will have specific contents in the operand field that selects the specific operand. A set of SIMD extensions known as Advanced Vector Extensions (AVX) (AVX1 and AVX2) and using the Vector Extension (VEX) encoding scheme have been released and / or published (e.g., see 64 and IA-32 Architectures Software Developer's Manual, September 2014; and see Advanced Vector Extensions Programming Reference, October 2014).

[0079] Example instruction format

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

[0081] Although embodiments will be described in which the vector friendly instruction format supports: 64-byte vector operand lengths (or sizes) with data element widths (or sizes) of 32 bits (4 bytes) or 64 bits (8 bytes) (thus, a 64-byte vector consists of 16 doubleword-sized elements or 8 quadword-sized elements); 64-byte vector operand lengths (or sizes) with data element widths (or sizes) of 16 bits (2 bytes) or 8 bits (1 byte); 32-byte vector operand lengths (or sizes) with data element widths (or sizes) of 32 bits (4 bytes), 64 bits (8 bytes), or 8 bits (1 byte). (8 bytes), 16 bits (2 bytes), or 8 bits (1 byte) data element width (or size); and a 16-byte vector operand length (or size) having a data element width (or size) of 32 bits (4 bytes), 64 bits (8 bytes), 16 bits (2 bytes), or 8 bits (1 byte); but alternative embodiments may support more, fewer, and / or different vector operand sizes (e.g., 256-byte vector operands) having more, fewer, or different data element widths (e.g., a data element width of 128 bits (16 bytes)).

[0082] Figure 7A is a block diagram illustrating an exemplary instruction format according to an embodiment. Figure 7A An instruction format 700 is shown that is specific in the sense that it specifies the location, size, interpretation, and order of fields, as well as the values of some of these fields. Instruction format 700 can be used to extend the x86 instruction set, so that some of the fields are similar or identical to those used in the existing x86 instruction set and its extensions (e.g., AVX). This format is consistent with the prefix encoding field, real opcode byte field, MOD R / M field, SIB field, displacement field, and immediate field of the existing x86 instruction set with extensions.

[0083] EVEX prefix (bytes 0-3) 702—encoded in four-byte form.

[0084] Format field 782 (EVEX byte 0, bits [7:0])—The first byte (EVEX byte 0) is the format field 782 and it contains 0x62 (a unique value used to distinguish the vector friendly instruction format in one embodiment).

[0085] The second through fourth bytes (EVEX bytes 1-3) include several bit fields that provide specific capabilities.

[0086] REX field 705 (EVEX byte 1, bits [7-5])—consists of the EVEX.R bit field (EVEX byte 1, bits [7]–R), the EVEX.X bit field (EVEX byte 1, bits [6]–X), and 757BEX byte 1, bits [5]–B). The EVEX.R, EVEX.X, and EVEX.B bit fields provide the same functionality as the corresponding VEX bit fields and are encoded using 1's complement form, i.e., ZMM0 is encoded as 1111B and ZMM15 is encoded as 0000B. The other fields of the instruction encode the lower three bits of the register index (rrr, xxx, and bbb) as is known in the art, such that Rrrr, Xxxx, and Bbbb can be formed by adding EVEX.R, EVEX.X, and EVEX.B.

[0087] REX' Field QAc10 - This is the EVEX.R' bit field (EVEX byte 1, bit [4] - R') used to encode the upper or lower 16 of the extended 32 register set. In one embodiment, this bit, along with the other bits shown below, are stored in bit-reversed format to distinguish it from the BOUND instruction (in the well-known x86 32-bit mode), which has a true opcode byte of 62 but does not accept a value of 11 in the MOD field in the MOD R / M field (described below); alternative embodiments do not store this bit and the other bits indicated below in bit-reversed format. A value of 1 is used to encode the lower 16 registers. In other words, R'Rrrr is formed by combining EVEX.R', EVEX.R, and the other RRRs from other fields.

[0088] Opcode map field 715 (EVEX byte 1, bits [3:0] - mmmm) - its contents encode the implied leading opcode byte (0F, 0F 38, or 0F 3).

[0089] Data element width field 764 (EVEX byte 2, bit [7] – W)—denoted by the symbol EVEX.W. EVEX.W is used to define the granularity (size) of the data type (32-bit data elements or 64-bit data elements). This field is optional because it is not needed if only one data element width is supported and / or if the data element width is supported by some aspect of the opcode.

[0090] EVEX.vvvv 720 (EVEX byte 2, bits [6:3]-vvvv)—The effects of EVEX.vvvv can include the following: 1) EVEX.vvvv encodes the first source register operand specified in inverted (one's complement) form and is valid for instructions with two or more source operands; 2) EVEX.vvvv encodes the destination register operand specified in inverted (one's complement) form for certain vector shifts; or 3) EVEX.vvvv does not encode any operand; this field is reserved and should contain 1111b. Thus, EVEX.vvvv field 720 encodes the four low-order bits of the first source register designator stored in inverted (one's complement) form. Depending on the instruction, an additional different EVEX bit field is used to extend the designator size to 32 registers.

[0091] EVEX.U 768 Class field (EVEX byte 2, bit [2] - U) - If EVEX.U = 0, it indicates Class A (supports merge-write masking) or EVEX.U0; if EVEX.U = 1, it indicates Class B (supports zeroing and merge-write masking) or EVEX.U1.

[0092] Prefix encoding field 725 (EVEX byte 2, bits [1:0]-pp)—Provides additional bits for the base operation field. In addition to providing support for legacy SSE instructions in the EVEX prefix format, this also has the benefit of compacting the SIMD prefix (the EVEX prefix only requires 2 bits, rather than a byte to express the SIMD prefix). In one embodiment, to support legacy SSE instructions that use SIMD prefixes (66H, F2H, F3H) in both the legacy and EVEX prefix formats, these legacy SIMD prefixes are encoded in the SIMD prefix encoding field and expanded to the legacy SIMD prefix at runtime before being provided to the decoder's PLA (thus, the PLA can execute both the legacy and EVEX formats of these legacy instructions without modification). While newer instructions can directly use the contents of the EVEX prefix encoding field as an opcode extension, some embodiments extend in a similar manner for consistency, but allow these legacy SIMD prefixes to specify different meanings. Alternative embodiments may redesign the PLA to support 2-bit SIMD prefix encodings, thus eliminating the need for expansion.

[0093] Alpha field 753 (EVEX byte 3, bit [7] - EH; also known as EVEX.EH, EVEX.rs, EVEX.RL, EVEX.WriteMaskControl, and EVEX.N; also illustrated as α) - its content distinguishes which of the different enhancement operation types is to be performed.

[0094] Beta field 755 (EVEX byte 3, bits [6:4] - SSS; also known as EVEX.s2-0, EVEX.r2-0, EVEX.rr1, EVEX.LL0, EVEX.LLB; also illustrated as βββ) - distinguishes which specific type of operation is to be performed.

[0095] REX' field 710 - This is the remainder of the REX' field and is the EVEX.V' bit field (EVEX byte 3, bit [3] - V') that can be used to encode the upper 16 or lower 16 of the extended 32-register set. This bit is stored in bit-reversed format. A value of 1 is used to encode the lower 16 registers. In other words, V'VVVV is formed by combining EVEX.V', EVEX.vvvv.

[0096] Write Mask Field 771 (EVEX Byte 3, Bits [2:0]-kkk)—its contents specify the index of the register in the Write Mask Register. In one embodiment, the special value EVEX.kkk=000 has special behavior, implying that no write mask is used for the particular instruction (this can be implemented in a variety of ways, including using a write mask hardwired to all ones or hardware that bypasses the masking hardware). When combined, 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 base and enhanced operations); in another embodiment, the old value of each element in the destination whose corresponding mask bit has a value of 0 is preserved. In contrast, the Zero Vector Mask allows any set of elements in the destination to be zeroed during the execution of any operation (specified by the base and enhanced operations); in one embodiment, elements of the destination are set to 0 if their corresponding mask bits have a value of 0. A subset of this functionality is the ability to control the vector length of the operation being performed (i.e., the stride of elements modified, from first to last); however, the modified elements do not have to be contiguous. Thus, write mask field 771 enables certain vector operations, including loads, stores, arithmetic, logical, etc. Although embodiments have been described in which the contents of write mask field 771 select one of several write mask registers containing the write mask to be used (such that the contents of write mask field 771 indirectly identify which masking to be performed), alternative embodiments alternatively or additionally allow the contents of mask write field 771 to directly specify the masking to be performed.

[0097] The real opcode field 730 (byte 4) is also called the opcode byte. A portion of the opcode is specified in this field.

[0098] The MOD R / M field 740 (Byte 5) includes a MOD field 742, a register index field 744, and an R / M field 746. The contents of the MOD field 742 distinguish between memory access and non-memory access operations. The role of the register index field 744 can be summarized into two scenarios: encoding a destination register operand or a source register operand, or being treated as an opcode extension and not used to encode any instruction operand. The contents of the register index field 744 directly specify or specify the location of the source or destination operand through address generation, whether in a register or in memory. These include a sufficient number of bits to select N registers from a PxQ (e.g., 32x512, 16x128, 32x1024, 64x1024) register file. While in one embodiment, N can be up to three source registers and one destination register, alternative embodiments may support more or fewer source and destination registers (e.g., up to two sources, one of which also serves as the destination; up to three sources, one of which also serves as the destination; or up to two sources and one destination).

[0099] The role of the R / M field 746 may include encoding an instruction operand that references a memory address, or encoding a destination register operand or a source register operand.

[0100] Scale, Index, Base (SIB) Byte (Byte 6) - The contents of the Scale field 750 allow the contents of the Index field to be scaled for memory address generation (e.g., for address generation using 2Scale * Index + Base). SIB.xxx 754 and SIB.bbb 756 - The contents of these fields were previously mentioned with respect to register indices Xxxx and Bbbb.

[0101] Displacement field 763A (bytes 7-10) - When the MOD field 742 contains 10, bytes 7-10 are the displacement field 763A and operate in the same manner as a traditional 32-bit displacement (disp32) and operate at byte granularity. This can be used as part of memory address generation (e.g., for address generation using 2 scale * index + base + displacement).

[0102] Displacement Factor Field 763B (Byte 7)—When MOD field 742 contains 01, byte 7 is the displacement factor field 763B. The location of this field is the same as for the traditional x86 instruction set 8-bit displacement (disp8), which operates at byte granularity. Because disp8 is sign-extended, it can only address offsets between -128 and 127 bytes. For a 64-byte cache line, disp8 uses 8 bits, which can be set to only four truly useful values: 128, -64, 0, and 64. Because a larger range is often required, disp32 is used; however, disp32 requires 4 bytes. Unlike disp8 and disp32, displacement factor field 763B is a reinterpretation of disp8. When displacement factor field 763B is used, the actual displacement is determined by multiplying the contents of the displacement factor field by the size (N) of the memory operand being accessed. This type of displacement is called disp8*N. This reduces the average instruction length (a single byte is used for the displacement, but with a much larger range). This compressed displacement is based on the assumption that the effective displacement is a multiple of the granularity of the memory access, and therefore, the redundant low-order bits of the address offset do not need to be encoded. In other words, the displacement factor field 763B replaces the traditional x86 instruction set 8-bit displacement. Thus, the displacement factor field 763B is encoded in the same manner as the x86 instruction set 8-bit displacement (so there is no change in the ModRM / SIB encoding rules), with the only exception that disp8 is overloaded to disp8*N. In other words, there is no change in the encoding rules or encoding length, only in the hardware's interpretation of the displacement value (the hardware needs to scale the displacement by the size of the memory operand to obtain the address offset in bytes).

[0103] The immediate field 772 allows the specification of an immediate value. This field is optional because it does not exist in implementations that do not support the general vector friendly format for immediate values and does not exist in instructions that do not use immediate values.

[0104] Full opcode field

[0105] Figure 7B is a block diagram illustrating the fields of instruction format 700 that make up full opcode field 774, according to one embodiment. Specifically, full opcode field 774 includes format field 782, base operation field 743, and data element width (W) field 763. Base operation field 743 includes prefix encoding field 725, opcode map field 715, and real opcode field 730.

[0106] Register index field

[0107] Figure 7Cis a block diagram illustrating, according to one embodiment, the fields of instruction format 700 that make up register index field 745. Specifically, register index field 745 includes REX field 705, REX' field 710, MODR / M.reg field 744, MODR / Mr / m field 746, VVVV field 720, xxx field 754, and bbb field 756.

[0108] Enhanced Action Field

[0109] Figure 7D is a block diagram illustrating the fields of instruction format 700 that make up the enhanced operation field, according to one embodiment. When the class (U) field 768 contains a 0, it indicates EVEX.U0 (class A 768A); when it contains a 1, it indicates EVEX.U1 (class B 768B). When U=0 and the MOD field 742 contains 11 (indicating a no memory access operation), the alpha field 753 (EVEX byte 3, bit [7] - EH) is interpreted as the rs field 753A. When the rs field 753A contains a 1 (round 753A.1), the beta field 755 (EVEX byte 3, bits [6:4] - SSS) is interpreted as the round control field 755A. The round control field 755A includes a one-bit SAE field 796 and a two-bit round operation field 798. When the rs field 753A contains 0 (data transformation 752A.2), the beta field 755 (EVEX byte 3, bits [6:4]-SSS) is interpreted as a three-bit data transformation field 755B. When U=0 and the MOD field 742 contains 00, 01, or 10 (indicating a memory access operation), the alpha field 753 (EVEX byte 3, bits [7]-EH) is interpreted as an eviction hint (EH) field 753B and the beta field 755 (EVEX byte 3, bits [6:4]-SSS) is interpreted as a three-bit data manipulation field 755C.

[0110] When U=1, the alpha field 753 (EVEX byte 3, bit [7]-EH) is interpreted as the write mask control (Z) field 753C. When U=1 and the MOD field 742 contains 11 (indicating no memory access operation), a portion of the beta field 755 (EVEX byte 3, bit [4]-S0) is interpreted as the RL field 757A; when it contains 1 (round 757A.1), the remainder of the beta field 755 (EVEX byte 3, bits [6-5]-S2-1) is interpreted as the round operation field 759A, and when the RL field 757A contains 0 (VSIZE 757.A2), the remainder of the beta field 755 (EVEX byte 3, bits [6-5]-S2-1) is interpreted as the vector length field 759B (EVEX byte 3, bits [6-5]-L1-0). When U=1 and the MOD field 742 contains 00, 01, or 10 (indicating a memory access operation), the beta field 755 (EVEX byte 3, bits [6:4] - SSS) is interpreted as a vector length field 759B (EVEX byte 3, bits [6-5] - L1-0) and a broadcast field 757B (EVEX byte 3, bits [4] - B).

[0111] Exemplary register architecture

[0112] Figure 8 7 is a block diagram of a register architecture 800 according to one embodiment. In the illustrated embodiment, there are 32 512-bit wide vector registers 810; these registers are referred to as ZMM0 through ZMM31. The low-order 256 bits of the lower 16 ZMM registers are overlaid on registers YMM0-16. The low-order 128 bits of the lower 16 ZMM registers (the low-order 128 bits of the YMM registers) are overlaid on registers XMM0-15. In other words, the vector length field 759B selects between a maximum length and one or more other shorter lengths, where each such shorter length is half the length of the previous length; and instruction templates without a vector length field 759B operate at the maximum vector length. In addition, in one embodiment, the class B instruction templates of the instruction format 700 operate on packed or scalar single / double-precision floating-point data and packed or scalar integer data. Scalar operations are operations performed on the lowest-order data element position in a ZMM / YMM / XMM register; higher-order data element positions are either left the same as they were before the instruction, or are zeroed, depending on the embodiment.

[0113] Write mask registers 815 - In the illustrated embodiment, there are eight write mask registers (k0 through k7), each 64 bits in size. In an alternative embodiment, the write mask registers 815 are 16 bits in size. In some embodiments, vector mask register k0 can be used as a write mask; while the encoding that would normally indicate k0 is used for a write mask, it selects a hardwired write mask of 0xFFFF, effectively disabling write masking for that instruction.

[0114] General purpose registers 825 - In the illustrated embodiment, there are sixteen 64-bit general purpose registers that are used with existing x86 addressing modes to address memory operands. These registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.

[0115] Scalar floating point stack register file (x87 stack) 845 (on which the MMX packed integer flat register file 850 is aliased)—in the illustrated embodiment, the x87 stack is an eight-element stack used to perform scalar floating point operations on 32 / 64 / 80-bit floating point data using the x87 instruction set extension; while the MMX registers are used to perform operations on 64-bit packed integer data, as well as to hold operands for some operations performed between MMX and XMM registers.

[0116] Alternative embodiments may use wider or narrower registers. Additionally, alternative embodiments may use more, fewer, or different register files and registers.

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

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

[0119] Exemplary core architecture

[0120] Figure 9A is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline, according to an embodiment. Figure 9B is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue / execution architecture core to be included in a processor, according to an embodiment. Figures 9A-9B The solid boxes in illustrate the in-order pipeline and in-order core, while the optional addition of dashed boxes illustrates 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.

[0121] exist Figure 9A , the processor pipeline 900 includes a fetch stage 902, a length decode stage 904, a decode stage 906, an allocation stage 908, a rename stage 910, a dispatch (also called a dispatch or issue) stage 912, a register read / memory read stage 914, an execute stage 916, a write back / memory write stage 918, an exception handling stage 922, and a commit stage 924.

[0122] Figure 9BProcessor core 990 is shown to include a front end unit 930 coupled to an execution engine unit 950, and both are coupled to a memory unit 970. Core 990 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 another option, core 990 can be a specialized core, such as a network or communication core, a compression engine, a coprocessor core, a general purpose computing graphics processing unit (GPGPU) core, a graphics core, or the like.

[0123] The front end unit 930 includes a branch prediction unit 932, which is coupled to an instruction cache unit 934, which is coupled to an instruction translation lookaside buffer (TLB) 936, which is coupled to an instruction fetch unit 938, which is coupled to a decode unit 940. The decode unit 940 (or decoder) can decode an instruction and generate one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals as output. These micro-operations, microcode entry points, microinstructions, other instructions, or other control signals are decoded from the original instruction, or otherwise reflect the original instruction, or are derived from the original instruction. The decode unit 940 can be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read-only memory (ROM), and the like. In one embodiment, core 990 includes a microcode ROM or other medium that stores microcode for certain macroinstructions (e.g., in decode unit 940 or otherwise within front end unit 930). Decode unit 940 is coupled to rename / allocator unit 952 in execution engine unit 950.

[0124] The execution engine unit 950 includes a rename / allocator unit 952, which is coupled to a retirement unit 954 and a set of one or more scheduler units 956. The scheduler unit(s) 956 represent any number of different schedulers, including reservation stations, central instruction windows, and the like. The scheduler unit(s) 956 are coupled to the physical register file(s) 958. Each of the physical register file units 958 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating point, packed integers, packed floating point, vector integers, vector floating point, 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 units 958 include a vector register unit, a write mask register unit, and a scalar register unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers. The physical register file(s) unit(s) 958 are overlaid with the retirement unit 954 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., utilizing reorder buffer(s) and retirement register file(s); utilizing future file(s), history buffer(s), and retirement register file(s); utilizing register maps and pools of registers; etc.). The retirement unit 954 and the physical register file(s) unit(s) 958 are coupled to the execution cluster(s) 960. The execution cluster(s) 960 include a set of one or more execution units 962 and a set of one or more memory access units 964. The execution units 962 can perform various 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 dedicated to a particular function or set of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. Scheduler unit(s) 956, physical register file unit(s) 958, and execution cluster(s) 960 are shown as potentially plural 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 unit, physical register file unit, and / or execution cluster—and in the case of a separate memory access pipeline, some embodiments are implemented where only the execution cluster for that pipeline has memory access unit(s) 964).It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, and the rest in-order.

[0125] A set of memory access units 964 is coupled to a memory unit 970, which includes a data TLB unit 972, which is coupled to a data cache unit 974, which is coupled to a level 2 (L2) cache unit 976. In one exemplary embodiment, the memory access unit 964 may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 972 in the memory unit 970. The instruction cache unit 934 is further coupled to a level 2 (L2) cache unit 976 in the memory unit 970. The L2 cache unit 976 is coupled to one or more other levels of cache and ultimately to main memory.

[0126] As an example, the exemplary register renaming, out-of-order issue / execution core architecture may implement pipeline 900 as follows: 1) instruction fetch 938 performs fetch and length decode stages 902 and 904; 2) decode unit 940 performs decode stage 906; 3) rename / allocator unit 952 performs allocate stage 908 and rename stage 910; 4) (one or more) scheduler units 956 performs dispatch stage 912; 5) (one or more) physical register file units 958 and memory units 970 perform register read / memory read stage 914; execution cluster 960 performs execute stage 916; 6) memory unit 970 and (one or more) physical register file units 958 perform write back / memory write stage 918; 7) various units may be involved in exception handling stage 922; and 8) retirement unit 954 and (one or more) physical register file units 958 perform commit stage 924.

[0127] Core 990 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 from MIPS Technologies, Inc. of Sunnyvale, California; the ARM instruction set from ARM Holdings, Inc. of Sunnyvale, California (with optional additional extensions, such as NEON)), including the instruction(s) described herein. In one embodiment, core 990 includes logic to support packed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed with packed data.

[0128] Figure 10 FIG. 1 shows a block diagram of a SOC package according to an embodiment. Figure 10As shown, the SOC 1002 includes one or more central processing unit (CPU) cores 1020, one or more graphics processor unit (GPU) cores 1030, an input / output (I / O) interface 1040, and a memory controller 1042. The various components of the SOC package 1002 can be coupled to an interconnect or bus, such as discussed herein with reference to other figures. In addition, the SOC package 1002 can include more or fewer components, such as those discussed herein with reference to other figures. In addition, each component of the SOC package 1002 can include one or more other components, such as discussed herein with reference to other figures. In one embodiment, the SOC package 1002 (and its components) are provided on one or more integrated circuit (IC) dies, such as, for example, these dies are packaged into a single semiconductor device.

[0129] like Figure 10 As shown, the SOC package 1002 is coupled to the memory 1060 via the memory controller 1042. In one embodiment, the memory 1060 (or a portion thereof) may be integrated on the SOC package 1002.

[0130] The I / O interface 1040 can be coupled to one or more I / O devices 1070, for example, via an interconnect and / or bus, such as discussed herein with reference to other figures. The I / O device(s) 1070 may include one or more of the following: a keyboard, a mouse, a touchpad, a display, an image / video capture device (e.g., a camera or video / recorder), a touch screen, a speaker, and the like.

[0131] Figure 11 1 is a block diagram of a processing system 1100 according to one embodiment. In various embodiments, system 1100 includes one or more processors 1102 and one or more graphics processors 1108, and can be a single-processor desktop system, a multi-processor workstation system, or a server system with a large number of processors 1102 or processor cores 1107. In one embodiment, system 1100 is a processing platform contained within a system-on-chip (SoC or SOC) integrated circuit for use in mobile, handheld, or embedded devices.

[0132] Embodiments of system 1100 may include or be included in the following: a game platform based on a server, a game console including a game and media console, a mobile game console, a handheld game console, or an online game console. In some embodiments, system 1100 is a mobile phone, a smart phone, a tablet computing device, or a mobile internet device. Data processing system 1100 may also include a wearable device, be coupled with the wearable device, or be integrated in the wearable device, such as a smart watch wearable device, smart glasses device, augmented reality device, or virtual reality device. In some embodiments, data processing system 1100 is a television or set-top box device with one or more processors 1102 and a graphical interface generated by one or more graphics processors 1108.

[0133] In some embodiments, one or more processors 1102 each include one or more processor cores 1107 to process instructions that, when executed, perform operations of the system and user software. In some embodiments, each of the one or more processor cores 1107 is configured to process a specific instruction set 1109. In some embodiments, the instruction set 1109 may facilitate complex instruction set computing (CISC), reduced instruction set computing (RISC), or computing via very long instruction words (VLIW). Multiple processor cores 1107 may each process a different instruction set 1109, which may include instructions that facilitate emulation of other instruction sets. The processor cores 1107 may also include other processing devices, such as a digital signal processor (DSP).

[0134] In some embodiments, the processor 1102 includes a cache memory 1104. Depending on the architecture, the processor 1102 may have a single internal cache or multiple levels of internal cache. In some embodiments, the cache memory is shared between various components of the processor 1102. In some embodiments, the processor 1102 also uses an external cache (e.g., a Level 3 (L3) cache or a Last Level Cache (LLC)) (not shown), which can be shared between the processor cores 1107 using known cache coherence techniques. Also included in the processor 1102 is a register file 1106, which may include different types of registers (e.g., integer registers, floating point registers, status registers, and an instruction pointer register) for storing different types of data. Some registers may be general-purpose registers, while other registers may be specific to the design of the processor 1102.

[0135] In some embodiments, processor 1102 is coupled to a processor bus 1110 to transmit communication signals, such as address, data, or control signals, between processor 1102 and other components in system 1100. In one embodiment, system 1100 utilizes an exemplary "hub" system architecture, including a memory controller hub 1116 and an input / output (I / O) controller hub 1130. Memory controller hub 1116 facilitates communication between memory devices and other components of system 1100, while I / O controller hub (ICH) 1130 provides connectivity to I / O devices via a local I / O bus. In one embodiment, the logic of memory controller hub 1116 is integrated within the processor.

[0136] The memory device 1120 may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory device, a phase change memory device, or some other memory device with suitable performance for use as process memory. In one embodiment, the memory device 1120 may serve as system memory for the system 1100 to store data 1122 and instructions 1121 for use when one or more processors 1102 execute applications or processes. The memory controller hub 1116 is also coupled to an optional external graphics processor 1112, which may communicate with one or more graphics processors 1108 in the processor 1102 to perform graphics and media operations.

[0137] In some embodiments, the ICH 1130 enables peripherals to connect to the memory device 1120 and the processor 1102 via a high-speed I / O bus. I / O peripherals include, but are not limited to, an audio controller 1146, a firmware interface 1128, a wireless transceiver 1126 (e.g., Wi-Fi, Bluetooth), a data storage device 1124 (e.g., a hard drive, flash memory, etc.), and a legacy I / O controller 1140 for coupling legacy (e.g., Personal System 2 (PS / 2)) devices to the system. One or more Universal Serial Bus (USB) controllers 1142 connect input devices, such as a keyboard and mouse 1144 combination. A network controller 1134 may also be coupled to the ICH 1130. In some embodiments, a high-performance network controller (not shown) is coupled to the processor bus 1110. It will be understood that the illustrated system 1100 is exemplary and not limiting, as other types of data processing systems with different configurations may also be used. For example, I / O controller hub 1130 may be integrated within one or more processors 1102 , or memory controller hub 1116 and I / O controller hub 1130 may be integrated into a discrete external graphics processor, such as external graphics processor 1112 .

[0138] Figure 12 is a block diagram of an embodiment of a processor 1200 having one or more processor cores 1202A through 1202N, an integrated memory controller 1214 , and an integrated graphics processor 1208 . Figure 12 Elements having the same reference numerals (or names) as elements in any other figures herein may operate or function in any manner similar to, but not limited to, those described elsewhere herein. Processor 1200 may include additional cores, up to and including additional core 1202N represented by a dashed box. Each of processor cores 1202A through 1202N includes one or more internal cache units 1204A through 1204N. In some embodiments, each processor core may also have access to one or more shared cache units 1206.

[0139] Internal cache units 1204A through 1204N and shared cache unit 1206 represent a cache memory hierarchy within processor 1200. The cache memory hierarchy may include at least one level of instruction and data cache within each processor core and one or more levels of shared intermediate level cache, such as level 2 (L2), level 3 (L3), level 4 (L4), or other levels of cache, with the highest level of cache before external memory being categorized as LLC. In some embodiments, cache coherence logic maintains coherence between the various cache units 1206 and 1204A through 1204N.

[0140] In some embodiments, processor 1200 may further include a set of one or more bus controller units 1216 and a system agent core 1210. The one or more bus controller units 1216 manage a set of peripheral buses, such as one or more peripheral component interconnect buses (e.g., PCI, PCI Express). System agent core 1210 provides management functions for various processor components. In some embodiments, system agent core 1210 includes one or more integrated memory controllers 1214 to manage access to various external memory devices (not shown).

[0141] In some embodiments, one or more of the processor cores 1202A through 1202N include support for simultaneous multithreading. In such embodiments, the system agent core 1210 includes components for coordinating and operating the cores 1202A through 1202N during multithreaded processing. The system agent core 1210 may also include a power control unit (PCU) that includes logic and components for regulating the power state of the processor cores 1202A through 1202N and the graphics processor 1208.

[0142] In some embodiments, processor 1200 also includes a graphics processor 1208 to perform graphics processing operations. In some embodiments, graphics processor 1208 is coupled to a set of shared cache units 1206 and a system agent core 1210 (including one or more integrated memory controllers 1214). In some embodiments, a display controller 1211 is coupled to graphics processor 1208 to drive the graphics processor output to one or more coupled displays. In some embodiments, display controller 1211 can be a separate module coupled to the graphics processor via at least one interconnect, or can be integrated within graphics processor 1208 or system agent core 1210.

[0143] In some embodiments, a ring-based interconnect 1212 is used to couple the internal components of the processor 1200. However, alternative interconnects may be used, such as point-to-point interconnects, switched interconnects, or other technologies, including those known in the art. In some embodiments, the graphics processor 1208 is coupled to the ring interconnect 1212 via an I / O link 1213.

[0144] Exemplary I / O links 1213 represent at least one of several varieties of I / O interconnects, including on-package I / O interconnects, that facilitate communication between various processor components and high-performance embedded memory modules 1218, such as eDRAM (or embedded DRAM) modules. In some embodiments, each of processor cores 1202 through 1202N and graphics processor 1208 use embedded memory modules 1218 as a shared last-level cache.

[0145] In some embodiments, processor cores 1202A through 1202N are homogeneous cores that execute the same instruction set architecture. In another embodiment, processor cores 1202A through 1202N are heterogeneous with respect to instruction set architecture (ISA), wherein one or more of processor cores 1202A through 1202N execute a first instruction set, while at least one of the other cores executes a subset of the first instruction set or a different instruction set. In one embodiment, processor cores 1202A through 1202N are heterogeneous with respect to microarchitecture, wherein one or more cores with relatively higher power consumption are coupled with one or more power cores with lower power consumption. Furthermore, processor 1200 may be implemented on one or more chips, or as a SoC integrated circuit having the illustrated components in addition to other components.

[0146] Figure 13 13 is a block diagram of a graphics processor 1300, which can be a discrete graphics processing unit or a graphics processor integrated with multiple processing cores. In some embodiments, the graphics processor communicates with registers on the graphics processor and commands placed into processor memory via a memory-mapped I / O interface. In some embodiments, graphics processor 1300 includes a memory interface 1314 for accessing memory. Memory interface 1314 can be an interface to local memory, one or more internal caches, one or more shared external caches, and / or system memory.

[0147] In some embodiments, the graphics processor 1300 also includes a display controller 1302 to drive display output data to a display device 1320. The display controller 1302 includes hardware for one or more overlay planes for displaying and compositing multiple layers of video or user interface elements. In some embodiments, the graphics processor 1300 includes a video codec engine 1306 to encode media into one or more media coding formats, decode media from one or more media coding formats, or transcode media between one or more media coding formats, including but not limited to Moving Picture Experts Group (MPEG) formats such as MPEG-2, Advanced Video Coding (AVC) formats such as H.264 / MPEG-4 AVC, and Society of Motion Picture & Television Engineers (SMPTE) 321M / VC-1, and Joint Photographic Experts Group (JPEG) formats such as JPEG and Motion JPEG (MJPEG).

[0148] In some embodiments, graphics processor 1300 includes a block image transfer (BLIT) engine 1304 to perform two-dimensional (2D) rasterizer operations, including, for example, bit-boundary block transfers. However, in one embodiment, 3D graphics operations are performed using one or more components of a graphics processing engine (GPE) 1310. In some embodiments, graphics processing engine 1310 is a compute engine that performs graphics operations, including three-dimensional (3D) graphics operations and media operations.

[0149] In some embodiments, GPE 1310 includes a 3D pipeline 1312 for performing 3D operations, such as rendering three-dimensional images and scenes, using processing functions that operate on 3D primitive shapes (e.g., rectangles, triangles, etc.). 3D pipeline 1312 includes programmable and fixed functional elements that perform various tasks within the element and / or spawn execution threads to 3D / media subsystem 1315. While 3D pipeline 1312 can be used to perform media operations, one embodiment of GPE 1310 also includes a media pipeline 1316, which is specifically designed to perform media operations, such as video post-processing and image enhancement.

[0150] In some embodiments, media pipeline 1316 includes fixed-function or programmable logic units to perform one or more specialized media operations, such as video decoding acceleration, video deinterlacing, and video encoding acceleration, in place of or on behalf of video codec engine 1306. In some embodiments, media pipeline 1316 also includes a thread spawning unit for spawning threads for execution on 3D / media subsystem 1315. The spawned threads perform computations for the media operations on one or more graphics execution units included in 3D / media subsystem 1315.

[0151] In some embodiments, 3D / media subsystem 1315 includes logic for executing threads spawned by 3D pipeline 1312 and media pipeline 1316. In one embodiment, the pipelines send thread execution requests to 3D / media subsystem 1315, which includes thread dispatch logic for arbitrating and dispatching various requests to available thread execution resources. Execution resources include an array of graphics execution units that handle 3D and media threads. In some embodiments, 3D / media subsystem 1315 includes one or more internal caches for thread instructions and data. In some embodiments, the subsystem also includes shared memory, including registers and addressable memory, to share data between threads and store output data.

[0152] In the following description, many specific details are described to provide a more thorough understanding. However, it will be clear to those skilled in the art that the embodiments described herein can be implemented without one or more of these specific details. In other cases, well-known features are not described to avoid obscuring the details of these embodiments.

[0153] The following examples relate to further embodiments. Example 1 includes an apparatus comprising: a memory for storing a decompression application programming interface (API), the decompression API for receiving an input handle to a data object, wherein the data object includes compressed data and metadata; and a decompression engine (DE) circuit for decompressing the compressed data to generate uncompressed data, the DE circuit for decompressing the compressed data in response to a call to a decompression instruction by the decompression API, wherein the metadata includes: a first operation object for indicating a location of the compressed data; a second operation object for indicating a size of the compressed data; a third operation object for indicating a location where the decompressed data of the DE circuit is to be stored; and a fourth operation object for indicating the size of the decompressed data. Example 2 includes the apparatus of Example 1, wherein the compression API is for providing the second operation object. Example 3 includes the apparatus of Example 2, wherein the memory is for storing the compression API. Example 4 includes the apparatus of Example 1, wherein the compression API is for compressing the input data to generate the compressed data. Example 5 includes the apparatus of Example 4, wherein the compression API is configured to compress the input data according to a deflate function. Example 6 includes the apparatus of Example 4, wherein the compression API is configured to insert the compressed data and the metadata into the data object. Example 7 includes the apparatus of Example 1, wherein the DE circuit is configured to decompress the compressed data according to the metadata. Example 8 includes the apparatus of Example 1, wherein the decompression instruction is configured to cause the DE circuit to perform out-of-order decompression of a plurality of cache lines. Example 9 includes the apparatus of Example 1, wherein the DE circuit is configured to notify a processor core after decompression of each of one or more cache lines, wherein the one or more cache lines are configured to store the compressed data and / or the decompressed data. Example 10 includes the apparatus of Example 9, wherein the DE circuit is configured to notify the processor core via a dedicated signal, a modification of a status bit in a register, or a modification of a status bit in a cache coupled to the processor core. Example 11 includes the apparatus of Example 1, wherein one or more of the first operand and the third operand comprises a virtual memory address. Example 12 includes the apparatus of Example 1, wherein a processor core, the DE circuit, and the memory are on a single integrated circuit die. Example 13 includes the apparatus of Example 12, wherein the processor core comprises a graphics processing unit (GPU) core.

[0154] Example 14 includes one or more non-transitory computer-readable media comprising one or more instructions that, when executed on at least one processor, configure the at least one processor to perform one or more operations for: causing a decompression application programming interface (API) to receive an input handle to a data object, wherein the data object includes compressed data and metadata; and causing a decompression engine (DE) circuit to decompress the compressed data to generate uncompressed data, the DE circuit decompressing the compressed data in response to a call to the decompression instruction by the decompression API, wherein the metadata includes: a first operation object indicating a location of the compressed data; a second operation object indicating a size of the compressed data; a third operation object indicating a location where the decompressed data is to be stored by the DE circuit; and a fourth operation object indicating the size of the decompressed data. Example 15 includes one or more computer-readable media as described in Example 14, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations for causing the compression API to provide the second operation object. Example 16 includes the one or more computer-readable media of Example 15, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the compression API to be stored in a memory. Example 17 includes the one or more computer-readable media of Example 14, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the compression API to compress input data to generate the compressed data. Example 18 includes the one or more computer-readable media of Example 17, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the compression API to compress the input data according to a deflate function. Example 19 includes the one or more computer-readable media of Example 17, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the compression API to insert the compressed data and the metadata into the data object. Example 20 includes one or more computer-readable media as described in Example 14, further including one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations so that the DE circuit decompresses the compressed data based on the metadata.Example 21 includes the one or more computer-readable media of Example 14, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the DE circuit to perform out-of-order decompression of a plurality of cache lines. Example 22 includes the one or more computer-readable media of Example 14, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the DE circuit to notify a processor core after decompression of each of one or more cache lines storing the compressed data and / or the decompressed data. Example 23 includes the one or more computer-readable media of Example 22, further comprising one or more instructions that, when executed on the at least one processor, configure the at least one processor to perform one or more operations to cause the DE circuit to notify the processor core via a dedicated signal, a modification of a status bit in a register, or a modification of a status bit in a cache coupled to the processor core. Example 24 includes the one or more computer-readable media of Example 14, wherein one or more of the first operand and the third operand comprise a virtual memory address.

[0155] Example 25 includes an apparatus comprising means for performing a method as recited in any of the preceding examples. Example 26 includes a machine-readable storage device comprising machine-readable instructions that, when executed, implement a method as recited in any of the preceding examples or implement a device as recited in any of the preceding examples.

[0156] In various embodiments, reference Figure 1 One or more operations discussed in the figures and thereafter may be performed by one or more components (interchangeably referred to herein as "logic") discussed with reference to any of the figures.

[0157] In various embodiments, the operations discussed herein, such as with reference to Figure 1 The operations discussed in the figures below may be implemented as hardware (e.g., logic circuits), software, firmware, or a combination thereof, which may be provided as a computer program product, for example, including one or more tangible (e.g., non-transitory) machine-readable or computer-readable media having stored thereon instructions (or software processes) for programming a computer to perform the processes discussed herein. The machine-readable media may include storage devices, such as those discussed with respect to the figures.

[0158] In addition, such computer-readable media may be downloaded as a computer program product, where the program may be transmitted from a remote computer (e.g., a server) to a requesting computer (e.g., a client) via a communication link (e.g., a bus, a modem, or a network connection) by a data signal provided in a carrier wave or other propagation medium.

[0159] References in this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, and / or characteristic described in connection with the embodiment may be included in at least one implementation. The phrase "in one embodiment" appearing in various places in this specification may or may not all refer to the same embodiment.

[0160] Additionally, in the specification and claims, the terms "coupled" and "connected," and their derivatives, may be used. In some embodiments, "connected" may be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements may not be in direct contact with each other, but may still cooperate or interact with each other.

[0161] Thus, although the embodiments are described in language specific to structural features and / or methodological acts, it is to be understood that the claimed subject matter may not be limited to the specific features or acts described. Rather, these specific features and acts are disclosed as sample forms of implementing the claimed subject matter.

Claims

1. A processing device comprising: a first memory for storing data objects, wherein the data objects include compressed data and uncompressed metadata; a plurality of cores coupled to the first memory, wherein a core of the plurality of cores comprises: Circuitry that, in response to one or more instructions, performs the following operations: loading the data object from the first memory; decompressing the compressed data based on the metadata to generate decompressed data; and storing the decompressed data in a memory of the core; The metadata is used to indicate a corresponding portion of the compressed data to be used to generate the decompressed data.

2. The processing device according to claim 1, wherein The one or more instructions include a first one or more instructions, and the apparatus further includes execution circuitry for executing a second one or more instructions to process the decompressed data.

3. The processing device according to claim 1 or 2, wherein Each respective portion of the compressed data includes a corresponding cache line.

4. The processing device according to any one of claims 1 to 3, wherein The field of the one or more instructions is used to indicate the location of the data object in the first memory.

5. The processing device according to any one of claims 1 to 4, wherein The bit mask consists of 64 bits.

6. The processing device according to any one of claims 1 to 5, wherein The data object comprises a first data object among a plurality of data objects to be stored in the first memory.

7. The processing device according to any one of claims 1 to 6, wherein: The compressed data is compressed by lossless compression.

8. The processing device according to any one of claims 1 to 7, wherein The processing device is integrated in an integrated circuit IC.

9. The processing device according to any one of claims 1 to 8, further comprising: An on-chip interconnect coupled to the first memory, wherein the core further comprises an interface for coupling the core to the on-chip interconnect and a second memory for storing the one or more instructions.

10. The processing device according to claim 9, wherein The circuit is configured to load the data object from the first memory via the on-chip interconnect.

11. The processing device according to claim 1, wherein The metadata includes a bit mask, each set bit of the bit mask being used to indicate a corresponding portion of the compressed data to be used to generate the decompressed data.

Images