FIELD
The present disclosure generally relates to the field of computing. More particularly, an embodiment of the invention generally relates to accelerating execution of compressed code.
BACKGROUND
Many applications are sensitive to code size footprint. One key example is mobile applications, which may use Read-Only Memory (ROM) based systems where the persistent memory storage is a key factor in overall system cost, size, or power consumption. In some instances, code compression may be used to mitigate at least some of these issues, sometimes with a performance decrease and/or power consumption increase due to the required on-the-fly decompression of the compressed code.
BRIEF DESCRIPTION OF THE DRAWINGS
The detailed description is provided with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.
FIGS. 1 and 2 illustrate embedded code compression before and after compressing, respectively.
FIGS. 3, 5, and 7 illustrate block diagrams of pipelined decompressors, according to some embodiments.
FIGS. 4 and 6 illustrate the data flowing into the pipelined decompressors, according to some embodiments.
FIG. 8 illustrates a flow diagram of a method according to an embodiment of the invention.
FIGS. 9 and 10 illustrate block diagrams of embodiments of computing systems, which may be utilized to implement some embodiments discussed herein.
FIG. 11 illustrates a block diagram of a wireless local area or cellular network communication system in accordance with some embodiments.
DETAILED DESCRIPTION
In the following description, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. However, various embodiments of the invention may be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the particular embodiments of the invention. Further, various aspects of embodiments of the invention may be performed using various means, such as integrated semiconductor circuits (“hardware”), computer-readable instructions organized into one or more programs (“software”), or some combination of hardware and software. For the purposes of this disclosure reference to “logic” shall mean either hardware, software (including for example micro-code that controls the operations of a processor), or some combination thereof.
Some embodiments enhance a two-level embedded code decompression scheme, e.g., by reducing or eliminating the performance overhead for the most frequently executed code flows, reducing power consumption, and/or reducing code size. Generally, embedded code compression aims to identify a set of unique bit patterns that compose an embedded code word and to store them in a table (also referred to as a “dictionary”). The compressed embedded code stores a (short) unique identifier for each pattern in the original embedded code word sequence, as shown in FIGS. 1 and 2. Moreover, an embodiment uses the flexibility in designating locations for values in the code dictionaries or memories to enable more efficient derivation of initial pointer values. Such embodiments may achieve the benefits provided by embedded code compression, while avoiding the extra costs in decompression performance.
In FIGS. 1 and 2, addr refers to the address of an embedded code instruction. In the uncompressed form (see, e.g., FIG. 1), the addr directly accesses the ROM to fetch an embedded code instruction (instr). In the compressed form (see, e.g., FIG. 2), the unique embedded code instructions are stored in the “unique patterns” table/array 202 (or dictionary), and only the index (pointer) to the pattern is stored in the original slot of the embedded code instructions (pointers array 204). This organization uses a 2-stage process to decompress an embedded code word: in the first stage the Pointers Array 204 is accessed to fetch an index (pointer) into the Unique Pattern array 202, which is in turn accessed to provide the word. Assume the original ROM has 6500 embedded code words each with 312 bits, and there are a total of 2005 unique embedded code words. The original ROM takes (312×6500) 2,028,000 bits and the compressed ROM takes only (6500*11+312*2005) 697,060 bits (where 11 is the number of bits required to index the 2005 entries in the unique pattern array 202). Hence, the compression ratio (compressed size/original size) is 34.37%. Accordingly, previous approaches to embedded code decompression may incur a performance cost at flow changes. To this end, some embodiments avoid this performance hit while enabling compression.
In various embodiments, the pointers arrays and unique pattern arrays/tables discussed herein may be implemented on separate storage units (such as memories discussed with reference to FIG. 9 or 10) or as regions within a same storage unit (such as memories discussed with reference to FIG. 9 or 10).
FIG. 3 illustrates a block diagram of a pipelined decompressor, according to an embodiment. In FIGS. 3, 5, and 7, R1, R2, and R3 refer to registers or first-in, first-out (FIFO) buffers that may be used to temporary store data passing between pipeline stages. FIG. 4 illustrates data flowing into the pipelined decompressor of FIG. 3 in accordance with an embodiment.
Referring to FIG. 3, the compressed organization utilizes an indirect access to the “unique patterns” table 302. This indirection increases the time required to fetch an instruction from the memory that stores code. Notice that before fetching the instruction from the unique patterns array 302, the pointer is fetched from the pointers array 304. If the time period to fetch from both arrays 302 and 304 is not small enough to fit within the processor cycle time (i.e., is less than or equal to one cycle of the processor), it can affect the processor performance. In order to ensure that this time period fits within the processor cycle time, the compressed ROM may use only fixed-sized code instructions and/or be pipelined. FIG. 3 shows the decompressor pipelined with two stages. The first pipeline stage includes the pointers array 304 and the second pipeline stage includes the unique patterns table/array 302.
During execution, a sequence of ‘addr’ addresses is presented to the compressed ROM. In the pipeline decompressor of FIG. 3, the address is initially presented to the Pointers Array 304. In the next stage, this produces pointer(s) that access the Unique Pattern array 302, while simultaneously a new ‘addr’ is presented to the pointers array 304, with a throughput of one word per cycle. This pipelined organization incurs a one-cycle ‘bubble’ whenever a new sequence of ‘addr’ is started. A “bubble” happens when the pipeline is restarted. This happens, for example, at the beginning of an embedded code flow, or during jumps. Generally, a “bubble” is figurative representation that indicates that the pipeline stage (the one that contains the bubble) is not performing any useful work.
Referring to FIG. 4, the data flowing into the pipelined decompressor of FIG. 3 is shown. In the first cycle (Cycle 1), the input of the pointers array 304 contains the first instruction address (Addr1). In the second cycle (Cycle 2), the second instruction address (Addr2) is provided to the pointers array 304 while the first pointer (Pointer 1) is provided to the unique patterns array 302. The bubble at R2 happens because the decompressor cannot provide the pointer to the unique pattern array in the first cycle.
FIG. 5 illustrates a block diagram of a pipelined decompressor, according to an embodiment. The embodiment of FIG. 5 avoids the bubble at R1, discussed with reference to FIGS. 3-4, by providing the first pointer (Pointer 1) directly (e.g., bypassing the pointers array 504) to the unique pattern array 502 at the same time the second address (Addr 2) is provided to the pointers array 504. As shown, a multiplexer may select the 1st pointer or an output of the pointers array 504 for transmission to the second pipeline via R2. Thus, the first instruction is fetched directly from the Unique Pattern array 502 in the first cycle of a new flow, while the address of the second instruction (‘addr’) is used to ‘prime’ the pipeline.
FIG. 6 shows the data flowing into the pipelined decompressor of FIG. 5, e.g., when the 1st pointer is provided directly to the unique patterns array. Notice that the bubble in the first cycle (Cycle 1) has been removed when compared with FIG. 4. In the first cycle, the input of the pointers array 504 contains the second instruction address and the input of the unique patterns array 502 includes the pointer to the 1st instruction. In the second cycle (Cycle 2), the third instruction address is provided to the pointers array 504 while the second pointer is provided to the unique patterns array 502. In this example, the decompressor is able to provide the pointer to the unique pattern array in the first cycle, eliminating the bubble.
FIG. 7 illustrates a block diagram of a pipelined decompressor, according to an embodiment. The organization in FIG. 5 is augmented in FIG. 7 by avoiding bus wiring for extra address bits (and logic). The 1st pointer is instead derived from the second instruction address (‘addr’) by a derivation logic 702. In an embodiment, the ‘Derivation logic’ may generate the 1st Pointer by selecting a subset of the bits in ‘addr’, so the logic to derive may be implemented simply by wiring the select bits to the multiplexer in at least one embodiment.
In one embodiment, by rearranging the location of the patterns in the unique patterns array we modify the values stored in the pointers array (the value of the pointers). For illustration, assume that the instruction “ADD R, R” is the first instruction in the embedded code flow. We can store this instruction pattern in the unique patterns array in a position where the index is a subset of the second instruction address (Addr2), so that the 1st pointer can be easily derived from the 2nd address. For example, if Addr1=000100, and Addr2=000101, the “ADD R, R” instruction could be stored in position 0101 in the unique patterns array, so that it's address could be directly derived from the low-order 4 bits of Addr2. At the start of a flow, Addr2 would be provided to R1, while its low-order 4 bits (0101) would be provided to R2, directly fetching the first instruction from the unique patterns array.
Also, such an embodiment may trade some compression (for enhanced performance), as it is conceivable that the “ADD R, R” instruction can be shared by another flow, requiring it to be duplicated in the unique patterns array to make its pointer data independent. However, this duplication only happens for (the relatively few) different instructions that are at the start of flows. Additionally, profiling could be used to select and optimize only the most frequently executed flows, leaving the bubble in the least frequently ones.
FIG. 8 illustrates a block diagram of a method 800 to enhance embedded codes, according to an embodiment. Operations of method 800 may be performed by one or more components discussed herein, e.g., with reference to FIGS. 1-7 and/or 9-11.
Referring to FIG. 8, at an operation 802, a compressed embedded code organization is determined (as previously described), e.g., generating a Pointer array and a Unique Pattern array, indexed by P and U bits, respectively. At an operation 804, a set S of embedded code addresses (addr) are identified, which are the second instructions of (e.g., important) flows. Moreover, the embedded code may contain multiple flows. Each flow contains a sequence of instructions. Each one of these instructions is associated with an address, such as: addr1, addr2, addr3, . . . , addrN. Addr2 is the address of the second instruction of a flow. Hence, operation 804 identifies the set of addresses that corresponds to the second instruction of each flow. Therefore, if the code has ten important flows or flows of interest, we will have a set with ten addresses, each one being the address of the second instruction in each flow. At an operation 806, for every element of S, the corresponding instruction patterns are added to the Unique Pattern array, for example, such that the pattern index can be easily derived from the second instruction address. In an embodiment, one could place the pattern in a position where the pattern index (composed of U bits) corresponds to a subset of the P bits of the second address (Addr2) in the flow.
Accordingly, in some embodiments, bubbles may be removed from an embedded compressed code flow to increase speed and/o reduce costs, by: (1) directly providing the pattern index for the first instruction in the flow to avoid the pipeline bubble; (2) deriving the pattern index from an instruction address; and/or (3) re-positioning patterns in the unique patterns array to simplify the logic to derive the pattern index from the instruction address.
In an embodiment, it is possible to trade compression ratio for performance by applying the techniques discussed herein (e.g., with reference to FIGS. 1-8) selectively. For example, the techniques may be restricted to important, short embedded instruction flows, which are more sensitive to the initial pipeline ‘bubble’ delays. Also, relatively long, rare, flows that are less sensitive to one extra cycle may be performed without utilizing such techniques. Furthermore, at the embedded code link stage, embedded code may be reorganized to minimize the number of distinct unique instructions that are at the start of flows; thus, preserving the compression ratio.
FIG. 9 illustrates a block diagram of an embodiment of a computing system 900. In various embodiments, one or more of the components of the system 900 may be provided in various electronic devices capable of performing one or more of the operations discussed herein with reference to some embodiments of the invention. For example, one or more of the components of the system 900 may be used to perform the operations discussed with reference to FIGS. 1-8 and 10-11. Also, various storage devices discussed herein (e.g., with reference to FIGS. 9 and/or 10) may be used to store data (including instructions), operation results, etc. In one embodiment, data associated with operations of method 900 of FIG. 9 may be stored in memory device(s) (such as memory 912 or one or more caches (e.g., L1, mid-level, or last level caches in an embodiment) present in processors 902 of FIG. 9 or 1002/1004 of FIG. 10).
Moreover, the computing system 900 may include one or more central processing unit(s) (CPUs) 902 or processors that communicate via an interconnection network (or bus) 904. The processors 902 may include a general purpose processor, a network processor (that processes data communicated over a computer network 903), or other types of a processor (including a reduced instruction set computer (RISC) processor or a complex instruction set computer (CISC)). Moreover, the processors 902 may have a single or multiple core design. The processors 902 with a multiple core design may integrate different types of processor cores on the same integrated circuit (IC) die. Also, the processors 902 with a multiple core design may be implemented as symmetrical or asymmetrical multiprocessors. Additionally, the processors 902 may utilize an SIMD (Single Instruction, Multiple Data) architecture. Moreover, the operations discussed with reference to FIGS. 1-8 may be performed by one or more components of the system 900. Also, as shown in FIG. 9, one or more of the processors 902 may include a (embedded) logic 990, which may be the same or similar to the decompressors discussed with reference to FIGS. 1-8. Other embodiments of the invention, however, may exist in other circuits, logic units, or devices within the system 900 of FIG. 9.
A chipset 906 may also communicate with the interconnection network 904. The chipset 906 may include a memory control hub (MCH) 908. The MCH 908 may include a memory controller 910 that communicates with a memory 912. The memory 912 may store data, including sequences of instructions that are executed by the CPU 902, or any other device included in the computing system 900. In one embodiment of the invention, the memory 912 may include one or more volatile storage (or memory) devices such as random access memory (RAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), static RAM (SRAM), or other types of storage devices. Nonvolatile memory may also be utilized such as a hard disk. Additional devices may communicate via the interconnection network 904, such as multiple CPUs and/or multiple system memories.
The MCH 908 may also include a graphics interface 914 that communicates with a display 916. The display 916 may be used to show a user results of operations associated with the Brownian Bridge algorithm discussed herein. In one embodiment of the invention, the graphics interface 914 may communicate with the display 916. In an embodiment of the invention, the display 916 may be a flat panel display that communicates with the graphics interface 914 through, for example, a signal converter that translates a digital representation of an image stored in a storage device such as video memory or system memory into display signals that are interpreted and displayed by the display 916. The display signals produced by the interface 914 may pass through various control devices before being interpreted by and subsequently displayed on the display 916.
A hub interface 918 may allow the MCH 908 and an input/output control hub (ICH) 920 to communicate. The ICH 920 may provide an interface to I/O devices that communicate with the computing system 900. The ICH 920 may communicate with a bus 922 through a peripheral bridge (or controller) 924, such as a peripheral component interconnect (PCI) bridge, a universal serial bus (USB) controller, or other types of peripheral bridges or controllers. The bridge 924 may provide a data path between the CPU 902 and peripheral devices. Other types of topologies may be utilized. Also, multiple buses may communicate with the ICH 920, e.g., through multiple bridges or controllers. Moreover, other peripherals in communication with the ICH 920 may include, in various embodiments of the invention, integrated drive electronics (IDE) or small computer system interface (SCSI) hard drive(s), USB port(s), a keyboard, a mouse, parallel port(s), serial port(s), floppy disk drive(s), digital output support (e.g., digital video interface (DVI)), or other devices.
The bus 922 may communicate with an audio device 926, one or more disk drive(s) 928, and a network interface device 930, which may be in communication with the computer network 903. In an embodiment, the device 930 may be a NIC capable of wireless communication. Other devices may communicate via the bus 922. Also, various components (such as the network interface device 930) may communicate with the MCH 908 in some embodiments of the invention. In addition, the processor 902 and the MCH 908 may be combined to form a single chip. Furthermore, the graphics interface 914 may be included within the MCH 908 in other embodiments of the invention.
Furthermore, the computing system 900 may include volatile and/or nonvolatile memory (or storage). For example, nonvolatile memory may include one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically EPROM (EEPROM), a disk drive (e.g., 928), a floppy disk, a compact disk ROM (CD-ROM), a digital versatile disk (DVD), flash memory, a magneto-optical disk, or other types of nonvolatile machine-readable media that are capable of storing electronic data (e.g., including instructions). In an embodiment, components of the system 900 may be arranged in a point-to-point (PtP) configuration such as discussed with reference to FIG. 10. For example, processors, memory, and/or input/output devices may be interconnected by a number of point-to-point interfaces.
More specifically, FIG. 10 illustrates a computing system 1000 that is arranged in a point-to-point (PtP) configuration, according to an embodiment of the invention. In particular, FIG. 10 shows a system where processors, memory, and input/output devices are interconnected by a number of point-to-point interfaces. The operations discussed with reference to FIGS. 1-9 and 11 may be performed by one or more components of the system 1000.
As illustrated in FIG. 10, the system 1000 may include several processors, of which only two, processors 1002 and 1004 are shown for clarity. The processors 1002 and 1004 may each include a local memory controller hub (MCH) 1006 and 1008 to couple with memories 1010 and 1012. The memories 1010 and/or 1012 may store various data such as those discussed with reference to the memory 912 of FIG. 9.
The processors 1002 and 1004 may be any suitable processor such as those discussed with reference to the processors 902 of FIG. 9. The processors 1002 and 1004 may exchange data via a point-to-point (PtP) interface 1014 using PtP interface circuits 1016 and 1018, respectively. The processors 1002 and 1004 may each exchange data with a chipset 1020 via individual PtP interfaces 1022 and 1024 using point to point interface circuits 1026, 1028, 1030, and 1032. The chipset 1020 may also exchange data with a high-performance graphics circuit 1034 via a high-performance graphics interface 1036, using a PtP interface circuit 1037.
At least one embodiment of the invention may be provided by utilizing the processors 1002 and 1004. For example, as shown in FIG. 10, one or more of the processors 1002/1004 may include a (embedded) logic 990, which may be the same or similar to the decompressors discussed with reference to FIGS. 1-8. Other embodiments of the invention, however, may exist in other circuits, logic units, or devices within the system 1000 of FIG. 10. Furthermore, other embodiments of the invention may be distributed throughout several circuits, logic units, or devices illustrated in FIG. 10.
The chipset 1020 may be coupled to a bus 1040 using a PtP interface circuit 1041. The bus 1040 may have one or more devices coupled to it, such as a bus bridge 1042 and I/O devices 1043. Via a bus 1044, the bus bridge 1043 may be coupled to other devices such as a keyboard/mouse 1045, the network interface device 1030 discussed with reference to FIG. 10 (such as modems, network interface cards (NICs), or the like that may be coupled to the computer network 903), audio I/O device, and/or a data storage device 1048. The data storage device 1048 may store code 1049 that may be executed by the processors 1002 and/or 1004.
Referring to FIG. 11, a block diagram of a wireless local area or cellular network communication system 1100 in accordance with one or more embodiments will be discussed. In the communication system 1100 shown in FIG. 11, a wireless device 1110 may include a wireless transceiver 1112 to couple to an antenna 1118 and to a logic 1114 such as a processor (e.g., to provide baseband and media access control (MAC) processing functions). In some embodiment, one or more of the computing systems discussed herein may include one or more of the components discussed with reference to the wireless device 1110. Also, computing devices 1102 may include one or more components of systems/devices discussed herein with reference to FIGS. 1-10.
In some embodiments, wireless device 1110 may be a cellular telephone or an information handling system such as a mobile personal computer or a personal digital assistant or the like that incorporates a cellular telephone communication module. Logic 1114 in one embodiment may comprise a single processor, or alternatively may comprise a baseband processor and an applications processor (e.g., where each processor discussed with reference to FIG. 11 may include one or more processor cores, or may be the same or similar to the processors discussed with reference to FIGS. 1-10). Logic 1114 couples to a memory 1116 which may include volatile memory such as dynamic random-access memory (DRAM), non-volatile memory such as flash memory, or alternatively may include other types of storage such as a hard disk drive. Some portion or all of memory 1116 may be included on the same integrated circuit as logic 1114, or alternatively some portion or all of memory 1116 may be disposed on an integrated circuit or other medium, for example a hard disk drive, that is external to the integrated circuit of logic 1114.
Wireless device 1110 may communicate with access point 1122 via a wireless communication link, where access point 1122 may include one or more of: an antenna 1120, a transceiver 1124, a processor 1126, and a memory 1128. As shown in FIG. 11, one or more of the wireless device 1110 and/or the access point 1122 may include a (embedded) logic 990, which may be the same or similar to the decompressors discussed with reference to FIGS. 1-10. In one embodiment, access point 1122 may be a base station of a cellular telephone network, and in another embodiment, access point 1122 may be a an access point or wireless router of a wireless local or personal area network. In an embodiment, access point 1122 (and optionally wireless device 1110) may include two or more antennas, for example to provide a spatial division multiple access (SDMA) system or a multiple input, multiple output (MIMO) system. Access point 1122 may couple with network 903, so that wireless device 1110 may communicate with network 903, including devices coupled to network 903, by communicating with access point 1122 via a wireless communication link. Network 903 may include a public network such as a telephone network or the Internet, or alternatively network 903 may include a private network such as an intranet, or a combination of a public and a private network. Communication between wireless device 1110 and access point 1122 may be implemented via a wireless local area network (WLAN). In one embodiment, communication between wireless device 1110 and access point 1122 may be at least partially implemented via a cellular communication network compliant with a Third Generation Partnership Project (3GPP or 3G) standard. In some embodiments, antenna 1118 may be utilized in a wireless sensor network or a mesh network.
In various embodiments of the invention, the operations discussed herein, e.g., with reference to FIGS. 1-11, may be implemented as hardware (e.g., logic circuitry), software (including, for example, micro-code that controls the operations of a processor such as the processors discussed herein, firmware, or combinations thereof, which may be provided as a computer program product, e.g., including a tangible machine-readable or computer-readable medium having stored thereon instructions (or software procedures) used to program a computer (e.g., a processor or other logic of a computing device) to perform an operation discussed herein. The machine-readable medium may include a storage device discussed herein.
Additionally, such tangible computer-readable media may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals in propagation medium via a communication link (e.g., a bus, a modem, or a network connection).
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least an implementation. The appearances of the phrase “in one embodiment” in various places in the specification may or may not be all referring to the same embodiment.
Also, in the description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. In some embodiments of the invention, “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.
Thus, although embodiments of the invention have been described in language specific to structural features and/or methodological acts, it is to be understood that claimed subject matter may not be limited to the specific features or acts described. Rather, the specific features and acts are disclosed as sample forms of implementing the claimed subject matter.
Patent Application
20110320775
