General purpose register hierarchy system and method

Abstract

The processing unit [100] includes a first memory device [106] and a second memory device [108]. The first memory device includes a first plurality of general purpose registers (GPRs) [112] and the second memory device includes a second plurality of GPRs [114]. The second memory device includes fewer GPRs than the first memory device. Program data is stored in the first memory device and the second memory device based on an expected access frequency associated with the program data.

Description

[Background technology]

[0001] Many processors include general purpose registers (GPRs) for storing temporary program data during program execution. GPRs are typically arranged in a memory device, such as a register file, located within the processor for fast access. Because GPRs are easily accessed by the processor, using a larger register file is desirable. In addition, some programs require a certain number of GPRs, and in some cases, a system with fewer GPRs than required can affect the system's ability to execute programs in a timely manner or, in some cases, without erroneous operation. Furthermore, in some cases, memory devices containing more GPRs are more area-efficient per bit than memory devices containing fewer GPRs. However, the power consumption of a memory device as part of read and write operations is proportional to the number of GPRs. As a result, accessing a GPR in a larger memory device consumes more power than accessing a GPR in a smaller memory device.

[0002] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings, in which: The use of the same reference numbers in different drawings indicates similar or identical items. [Brief explanation of the drawings]

[0003] [Figure 1] 1 is a block diagram of a processing unit including a GPR hierarchy according to some embodiments. [Figure 2] FIG. 1 is a block diagram of a compiler for a processing unit including a GPR hierarchy, according to some embodiments. [Figure 3] 1 is a flow diagram of a method for assigning GPRs according to some embodiments. [Figure 4] 1 is a flow diagram of a method for reassigning GPRs according to some embodiments. [Figure 5] 1 is a block diagram of a processing system including a GPR hierarchy according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0004] The processing unit includes multiple memory devices, each including a different respective number of general-purpose registers (GPRs). In some embodiments, the GPRs have the same design, and as a result, accesses to memory devices including fewer GPRs consume less power on average compared to memory devices including more GPRs. Also, because the processing unit includes memory devices including more GPRs, the processing unit can execute programs that require more GPRs than a processing system including only memory devices with fewer GPRs.

[0005] Additionally, in some programs, some program variables are used more frequently than others. In some embodiments, a processing unit identifies program variables that are expected to be accessed frequently. GPRs of memory devices that include fewer GPRs are assigned to the program variables that are expected to be accessed frequently. In some cases, memory devices that include fewer GPRs are accessed more frequently compared to an assignment scheme in which GPRs are simply assigned. As a result, the processing unit completes the program more quickly and / or using less power compared to a processing unit that uses simple assignment of GPRs. In some embodiments, because the program executes using less power, the processing unit is designed to include additional components, such as additional GPRs, without exceeding the power boundaries of the processing unit.

[0006] The techniques described herein may, in different embodiments, be employed using any of a variety of parallel processors (e.g., vector processors, graphics processing units (GPUs), general-purpose GPUs (GPGPUs), non-scalar processors, highly parallel processors, artificial intelligence (AI) processors, inference engines, machine learning processors, other multi-threaded processing units, etc.). For ease of explanation, reference is made herein to exemplary systems and methods in which processing modules are employed. However, it will be understood that the systems and techniques described herein apply equally to the use of other types of parallel processors, unless otherwise noted.

[0007] FIG. 1 illustrates a processing unit 100 including a GPR hierarchy, according to at least some embodiments. The processing unit 100 includes a controller 102, a plurality of compute units 104, a first memory device 106, a second memory device 108, and a third memory device 110. The first memory device 106 includes a GPR 112. The second memory device 108 includes a GPR 114. The third memory device 110 includes a GPR 116. In some embodiments, the processing unit 100 is a shader processing unit of a graphics processing unit, as described below with reference to FIG. 5. In other embodiments, the processing unit 100 is another type of processor. For clarity and ease of explanation, FIG. 1 includes only the components listed above. However, in other embodiments, additional components are contemplated, such as cache memory, memory devices that do not include a GPR, or additional memory devices that include a GPR. Furthermore, in some embodiments, fewer components are contemplated. For example, in some embodiments, processing unit 100 includes only two memory devices including a GPR, processing unit 100 includes only one computational unit, or both.

[0008] The compute units 104 execute programs using the program's machine code 124 and register data 120 stored in memory devices 106-110. In some cases, multiple compute units 104 execute respective portions of a single program in parallel. In other cases, each compute unit 104 executes its own program. In some embodiments, the compute units 104 are shader engines or arithmetic and logic units (ALUs) of a shader processing unit.

[0009] The memory devices 106-110 each include a different number of GPRs. In one example, the second memory device 108 includes fewer GPRs than the first memory device 106, and the third memory device 110 includes fewer GPRs than the second memory device 108. However, because the GPRs 112-116 share the same design, a read or write operation using GPR 112-4 consumes more power on average than a similar read or write operation using GPR 116-1. More specifically, when a memory device is used as part of a read operation, a certain amount of power is consumed per GPR in the memory device. As a result, when the GPRs share the same design, a read operation using a memory device that includes fewer GPRs consumes less power on average compared to a memory device that includes more GPRs. A similar relationship applies during a write operation. As a result, as described further below, register data 120 expected to be used more frequently is stored in GPR 116, and register data 120 expected to be used less frequently is stored in GPR 112. Thus, memory devices 106-110 are organized into a hierarchy. However, unlike a cache hierarchy, for example, in some embodiments, redundant data is not stored in slower memory devices, and memory devices are not accessed in the hope that a GPR will store the requested data. Processing unit 100 keeps track of where program data is stored. Furthermore, in some embodiments, GPRs are directly addressed, compared to caches, which are typically searched to find desired data because of how data moves between levels of the cache hierarchy. In embodiments where GPRs have different designs, other advantages, such as faster read times or different thermal characteristics, are exploited.

[0010] The controller 102 manages data in the processing unit 100. The controller 102 receives register data 120, which includes program data (e.g., variables) to be stored in memory devices 106-110 and to be used by one or more of the computation units 104 during program execution. In addition, the controller 102 receives access data 122, which indicates the expected access frequency of each variable of the program. In some cases, based on the access data 122, the controller 102 transmits some register data 120 to be stored in memory device 106, some register data 120 to be stored in memory device 108, and some register data 120 to be stored in memory device 110. The memory device 110 receives the register data 120 expected to be accessed most frequently (e.g., loop variables or multiply-accumulate data), and the memory device 106 receives the register data 120 expected to be accessed least frequently. Additionally, in the illustrated embodiment, during program execution, controller 102 reads GPRs 112-116 and causes register data 120 to be transmitted between memory devices 106-110 and computational units 104. In some cases, such as in response to a remapping event as described below with reference to FIG. 4, controller 102 retrieves register data 120 from a GPR of one memory device (e.g., GPR 112-2) and stores register data 120 in a GPR of another memory device (e.g., GPR 114-3) immediately after or after the register data 120 has been used by one or more of computational units 104.

[0011] In some embodiments, controller 102 determines access data 122. For example, controller 102 determines access data 122 by compiling program data into machine code 124. As another example, controller 102 determines access data 122 based on a register request received from a program (e.g., a program requesting that four variables be stored in memory device 110). As yet another example, controller 102 determines access data 122 based on register rules (e.g., a program-specific rule stating that only one GPR from memory device 110 is assigned to a particular program, or a particular variable is assigned a GPR from memory device 110, or a global rule stating that no more than three GPRs from memory device 108 are assigned to any one program). In various embodiments, access data 122 includes an indication of a remapping event. In response to the indication of the remapping event, controller 102 changes the assignment of at least one data value from a memory device (e.g., memory device 110) to another memory device (e.g., memory device 106). In some embodiments, the controller 102 is controlled by or executes a shader processing shader program.

[0012] 2 is a block diagram illustrating a program 202 and a compiler 204 of a processing unit (e.g., processing unit 100 of FIG. 1) that includes a GPR hierarchy, according to some embodiments. In the illustrated embodiment, compiler 204 includes a register usage analysis module 206. While the illustrated embodiment shows program 202, compiler 204, and register usage analysis module 206 as separate from the processing unit, in various embodiments, one or more of program 202, compiler 204, and register usage analysis module 206 are stored on or executed by portions of the processing unit. For example, in some embodiments, compiler 204 or register usage analysis module 206 is executed by a controller (e.g., controller 102) or by one or more of the compute units 104. As another example, in some embodiments, one or more memory devices 106-110 include additional storage configured to store program 202.

[0013] As described above, register data 120 is stored in a memory device based on the expected access frequency of register data 120. Compiler 204 receives program data 210, register requests 212, register rules 214, execution status 216, or any combination thereof, and uses register usage analysis module 206 to determine the expected access frequency based on the received data. For example, compiler 204 receives program data 210 from program 202 and translates program data 210 into machine code 124. In addition, compiler 204 uses register usage analysis module 206 to analyze program data 210, machine code 124, or both, and determines the expected access frequency corresponding to variables of the program based on cost heuristics. Compiler 204 then compares the expected access frequency with one or more access frequency thresholds and allocates the variables to memory devices having different numbers of GPRs. Compiler 204 indicates the variables via register data 120 and the allocations via access data 122. Additionally, compiler 204 monitors the execution status of program 202 via execution status 216 to potentially prevent compiler 204 from over-allocating GPRs. Furthermore, in some cases, allocating variables to memory devices is based on the number of unallocated GPRs in one or more of the memory devices.

[0014] In some embodiments, program 202 requests changes to the allocation of variables to memory devices. For example, program 202 requests that a particular variable be allocated to a particular memory device (e.g., memory device 110) via register request 212. As another example, program 202 requests that a particular number of GPRs in a particular memory device (e.g., memory device 108) be allocated to program 202 via register request 212.

[0015] In some embodiments, another entity (e.g., a user or another device) provides register rules 214 that affect the allocation of variables to a memory device. For example, a user specifies an access frequency threshold used to determine which variables are allocated to a memory device. As another example, register rules 214 include a program-specific rule that no more than a specified number of GPRs of a memory device are allocated to a program indicated by the program-specific rule. As a third example, register rules 214 include a global rule that no more than a specified number of GPRs of a memory device are allocated to any one program. To illustrate, in response to entering a power saving mode, the power management device indicates via register rules 214 that no GPRs of memory device 106 are allocated.

[0016] 4, in response to a remapping event (e.g., indicated by program data 210, register requests 212, register rules 214, execution status 216, or any combination thereof), compiler 204 moves register data 120 between memory devices. For example, in response to a high-priority program 202 requesting more GPRs 116 in memory device 110 than are currently available, compiler 204 moves some register data from another program to memory device 108. As another example, in response to that program finishing execution and therefore releasing GPRs 116, compiler 204 moves some register data from another program to memory device 110. As a third example, in response to the system entering the power-saving mode described above, compiler 204 moves some register data from memory device 106 to memory device 108, memory device 110, or both.

[0017] 3 and 4 illustrate an exemplary GPR allocation process according to at least some embodiments. As described above, variables are assigned to GPRs for a program based on expected access frequency. Figure 3 illustrates how program variables for a received program are assigned to a memory device. Figure 4 illustrates how program variables are reassigned in response to a remapping event.

[0018] 3 is a flow diagram illustrating a method for assigning GPRs, according to some embodiments. In some embodiments, method 300 is initiated by one or more processors in response to one or more instructions stored by a computer-readable storage medium. In some embodiments, various portions of method 300 occur in an order different from that shown. For example, in some cases, some program variables from a first set are assigned to GPRs in block 306 before other program variables are sorted into sets.

[0019] At block 302, program data is received. For example, compiler 204 receives program data 210 for program 202. At block 304, program variables are sorted into sets. For example, program variables in program data 210 are sorted into three sets corresponding to memory device 106, memory device 108, and memory device 110 by generating an estimated access frequency indicator for each program variable and comparing the estimated access frequency indicator to an access frequency threshold.

[0020] At block 306, a first set of program variables are assigned to GPRs of a first memory device. For example, program variables having estimated access frequency indicators that exceed all access frequency thresholds are assigned to GPRs of memory device 110. At block 308, a second set of program variables are assigned to GPRs of a second memory device. For example, program variables having estimated access frequency indicators that do not exceed an access frequency threshold are assigned to GPRs of memory device 106. Thus, a method for assigning GPRs is shown.

[0021] 4 is a flow diagram illustrating a method for reallocating GPRs, according to some embodiments. In some embodiments, method 400 is initiated by one or more processors in response to one or more instructions stored by a computer-readable storage medium. In some embodiments, various portions of method 400 are performed in a different order than shown or are omitted. For example, in some cases, the expected access frequency is not re-evaluated at block 404, and instead, a previously generated expected access frequency is used.

[0022] At block 402, an indication of a remapping event is received. For example, the compiler 204 receives an indication of a program requiring more GPRs 116 in the memory device 110 than are unallocated. As another example, the compiler 204 receives an indication of a program termination, deallocation of GPRs 116 in the memory device 110. At block 404, the expected access frequency of the program variables is re-evaluated. At block 406, the program variables are reallocated between memory banks. For example, if a program had four program variables that met the criteria to be allocated to the memory device 110, but only three GPRs 116 were available, then, in some cases, the fourth program variable is allocated to the GPR 114 in the memory device 108. If another GPR 116 in the memory device 110 is subsequently deallocated, then, in some cases, the program variable is moved from the memory device 108 to the memory device 110. Additionally, in some cases, other program variables are also re-evaluated. For example, in some embodiments, if a program includes a first loop for the first half of the program and a second loop for the second half of the program, depending on the timing of remapping events, the loop variable of the first loop is no longer expected to be accessed frequently and therefore is moved to a memory device containing more GPRs. Thus, a method for reallocating GPRs is shown.

[0023] 5 is a block diagram illustrating a computing system 500 including a processing unit 100 that includes a GPR hierarchy, according to some embodiments. The computing system 500 includes or has access to a system memory 505 or other storage components implemented using a non-transitory computer-readable storage medium, such as dynamic random-access memory (DRAM). However, in various embodiments, the system memory 505 is implemented using other types of memory, including static random-access memory (SRAM), non-volatile RAM, etc. The computing system 500 also includes a bus 510 for supporting communication between entities implemented in the computing system 500, such as the system memory 505. Some embodiments of the computing system 500 include other buses, bridges, switches, routers, etc., which are not shown in FIG. 5 for clarity.

[0024] Computing system 500 includes a processing system 540 that includes processing unit 100. In some embodiments, processing system 540 is a GPU that renders images for presentation on display 530. For example, in some cases, processing system 540 renders objects to generate pixel values ​​that are provided to display 530, which uses the pixel values ​​to display an image representing the rendered objects. In some embodiments, processing system 540 is a general-purpose processor (e.g., a CPU) or a GPU used for general-purpose computing. In the illustrated embodiment, processing system 540 performs multiple arithmetic operations in parallel using processing unit 100. For example, in some embodiments, processing system 540 is a GPU and processing unit 100 is a shader processing unit for processing aspects of an image, such as color, motion, lighting, and position of objects in the image. As described above, processing unit 100 includes a hierarchy of memory devices containing different amounts of GPUs, and processing unit 100 allocates program variables to the memory devices based on expected access frequency. While the illustrated embodiment shows the processing unit 100 as being entirely contained within the processing system 540, in other embodiments, the processing unit 100 includes fewer, additional, or different components, such as the compiler 204, that are located within the processing system 540 or elsewhere in the computing system 500 (e.g., the CPU 515). In some embodiments, the processing unit 100 is included elsewhere, such as separately connected to the bus 510 or within the CPU 515. In the illustrated embodiment, the processing system 540 communicates with the system memory 505 via the bus 510. However, some embodiments of the processing system 540 communicate with the system memory 505 via a direct connection or through other buses, bridges, switches, routers, etc. In some embodiments, the processing system 540 executes instructions stored in the system memory 505, and the processing system 540 stores information, such as results of executed instructions, in the system memory 505.For example, the system memory 505 stores a copy 520 of instructions from a program code that is executed by the processing system 540 .

[0025] Computing system 500 also includes a central processing unit (CPU) 515 configured to execute instructions simultaneously or in parallel. CPU 515 is connected to bus 510 and, in some embodiments, communicates with processing system 540 and system memory 505 via bus 510. In some embodiments, CPU 515 executes instructions, such as program code 545, stored in system memory 505, and CPU 515 stores information, such as results of executed instructions, in system memory 505. In some cases, CPU 515 initiates graphics operations by issuing draw calls to processing system 540.

[0026] An input / output (I / O) engine 525 handles input or output operations associated with the display 530 and other elements of the computing system 500, such as a keyboard, mouse, printer, external disk, etc. The I / O engine 525 is coupled to the bus 510 such that the I / O engine 525 can communicate with the system memory 505, the processing system 540, or the CPU 515. In the illustrated embodiment, the I / O engine 525 is configured to read information stored on an external storage component 535, which is implemented using a non-transitory computer-readable storage medium, such as a compact disk (CD), a digital video disk (DVD), or the like. In some cases, the I / O engine 525 writes information, such as results of processing by the processing system 540, the processing unit 100, or the CPU 515, to the external storage component 535.

[0027] As disclosed herein, in some embodiments, a system includes a first memory device including a first plurality of general-purpose registers (GPRs); a second memory device including a second plurality of GPRs, the second memory device having fewer GPRs than the first memory device; and a controller circuit configured to store data in the first plurality of GPRs, the second plurality of GPRs, or both based on an expected access frequency associated with the data. In one aspect, the controller circuit is configured to receive an expected access frequency associated with the data from a compiler that analyzes one or more programs that store data using the first memory device, the second memory device, or both. In another aspect, accessing one of the first plurality of GPRs consumes more power on average than accessing one of the second plurality of GPRs. In another aspect, the controller circuit is further configured to store at least a portion of the data in the second plurality of GPRs based on a GPR request from a program requesting allocation of a GPR of the second plurality of GPRs.

[0028] In one aspect, the controller circuit is further configured to store data in the first plurality of GPRs, the second plurality of GPRs, or both based on a register rule. In another aspect, the register rule includes a global rule that no more than a specified number of the second plurality of GPRs are assigned to any one program. In yet another aspect, the register rule includes a program-specific rule that no more than a specified number of the second plurality of GPRs are assigned to a program indicated by a program-specific rule. In yet another aspect, the system includes a third memory device comprising a third plurality of GPRs, the third memory device having fewer GPRs than the second memory device.

[0029] In some embodiments, a method includes, in a compiler, receiving program data for a program to be executed; sorting variables of the program into a first set of variables and a second set of variables, the second set of variables being expected to be accessed more frequently by the program than the first set of variables; indicating that the first set of variables are to be assigned to a first plurality of general-purpose registers (GPRs) of a first memory device; and indicating that the second set of variables are to be assigned to a second plurality of GPRs of a second memory device, where accessing one of the first plurality of GPRs consumes more power on average than accessing one of the second plurality of GPRs. In one aspect, sorting the variables of the program is based on a number of unassigned GPRs of the second plurality of GPRs. In another aspect, sorting the variables of the program is based on comparing the expected access frequency of each of the variables to an access frequency threshold.

[0030] In one aspect, the method includes adjusting the access frequency threshold based on a number of unassigned GPRs of the second plurality of GPRs. In another aspect, the method includes remapping at least one variable between the first and second plurality of GPRs in response to a remapping event. In yet another aspect, the remapping event includes an indication of overallocation of a GPR of the second plurality of GPRs or an indication of deallocation of a GPR of the second plurality of GPRs. In yet another aspect, the program indicates a requested number of GPRs to be assigned, and sorting the variables of the program is based on the requested number.

[0031] In some embodiments, the shader processing unit includes a first memory device including a first plurality of general purpose registers (GPRs); a second memory device including a second plurality of GPRs, where accessing one of the first plurality of GPRs consumes more power on average than accessing one of the second plurality of GPRs; and a plurality of shader engines configured to execute programs using data stored in the first memory device, the second memory device, or both. In one aspect, the shader processing unit includes a shader controller for moving data between a system memory and the first plurality of GPRs, the second plurality of GPRs, or both, based on an expected access frequency associated with the data. In another aspect, the shader controller further moves data between the first and second memory devices and the plurality of shader engines. In yet another aspect, the shader controller moves data from the first memory device to the first shader engine simultaneously with moving data from the second memory device to the second shader engine. In yet another aspect, the shader processing unit includes a shader compiler for compiling one or more programs that use data stored in the first memory device, the second memory device, or both, determining expected access frequencies associated with the program data based on a weighting process, and assigning the first plurality of GPRs, the second plurality of GPRs, or both GPRs to the one or more programs based on the expected access frequencies.

[0032] In some embodiments, a computer-readable storage medium includes any non-transitory storage medium or combination of non-transitory storage media that can be accessed by a computer system during use to provide instructions and / or data to the computer system. Such storage media may include, but are not limited to, optical media (e.g., compact discs (CDs), digital versatile discs (DVDs), Blu-ray discs), magnetic media (e.g., floppy disks, magnetic tape, magnetic hard drives), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or flash memory), or micro-electromechanical systems (MEMS)-based storage media. The computer-readable storage medium (e.g., system RAM or ROM) may be internal to the computing system, the computer-readable storage medium (e.g., a magnetic hard drive) may be permanently attached to the computing system, the computer-readable storage medium (e.g., an optical disk or Universal Serial Bus (USB)-based flash memory) may be removably attached to the computing system, or the computer-readable storage medium (e.g., network-accessible storage (NAS)) may be coupled to the computer system via a wired or wireless network.

[0033] In some embodiments, certain aspects of the techniques described above are implemented by one or more processors of a processing system executing software. The software includes one or more sets of executable instructions stored or otherwise tangibly embodied in a non-transitory computer-readable storage medium. The software may include instructions and specific data that, when executed by one or more processors, operate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium may include, for example, a magnetic or optical disk storage device, a solid-state storage device such as flash memory, a cache, a random access memory (RAM), or other non-volatile memory device(s). The executable instructions stored on the non-transitory computer-readable storage medium may be implemented as source code, assembly language code, object code, or other form of instructions that can be interpreted or otherwise executed by one or more processors.

[0034] In addition to the above, it should be noted that not all activities or elements described in the summary description are required, that some of the particular activities or devices may not be required, that one or more additional activities may be performed, and that one or more additional elements may be included. Furthermore, the order in which the activities are listed is not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, those skilled in the art will recognize that various modifications and variations can be made without departing from the scope of the invention as set forth in the claims. Accordingly, the specification and drawings should be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention.

[0035] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and features from which any benefit, advantage, or solution may arise or be manifested are not construed as critical, essential, or essential features of any or all claims. Moreover, the specific embodiments described above are illustrative only, since the disclosed invention may be modified and practiced in different, but similar manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the appended claims. It is therefore apparent that the specific embodiments described above may be altered or modified, and that all such variations are considered within the scope of the disclosed invention. Accordingly, the protection sought herein is set forth in the appended claims.

[0036] Within this disclosure, different entities (which may be variously referred to as "components," "units," "devices," etc.) may sometimes be described or claimed as being "configured" to perform one or more tasks or operations. This express phrase, an entity configured to perform one or more tasks, is used herein to refer to a structure (i.e., a physical thing, such as an electronic circuit). More specifically, this express phrase is used to indicate that the structure is adapted to perform one or more tasks during operation. A structure may be said to be "configured to" perform some task even if the structure is not currently being operated. A "memory device configured to store data," for example, is intended to encompass an integrated circuit having circuitry that stores data during operation, even if the subject integrated circuit is not currently being used (e.g., no power source is connected to it). Thus, an entity described or listed as being "configured" to perform some task refers to something physical, such as a device, circuit, memory that stores executable program instructions to perform a task. This phrase is not used herein to refer to something intangible. Furthermore, the term "configured to" is not intended to mean "configurable to." For example, an unprogrammed field programmable gate array is not considered to be "configured" to perform any particular function, but may be "configurable" to perform that function after programming. Additionally, reciting in the appended claims that a structure is "configured to" perform one or more tasks is clearly not intended to be construed as having means-plus-function elements.

Claims

1. 1. A system comprising: a first memory device including a first plurality of general purpose registers (GPRs); a second memory device different from the first memory device, the second memory device including a second plurality of GPRs, the second memory device having fewer GPRs than the first memory device, the first plurality of GPRs sharing a design with the second plurality of GPRs; a controller circuit configured to store the data in the first plurality of GPRs, the second plurality of GPRs, or both based on an expected access frequency associated with the data; system.

2. the controller circuit is configured to receive the expected access frequency associated with the data from a compiler that analyzes one or more programs that store data using the first memory device, the second memory device, or both. The system of claim 1.

3. accessing any of the first plurality of GPRs consumes more power on average than accessing any of the second plurality of GPRs; 3. The system of claim 1 or 2.

4. the controller circuit is configured to store at least a portion of the data in the second plurality of GPRs based on a GPR request from a program requesting allocation of a GPR in the second plurality of GPRs; The system of any one of claims 1 to 3.

5. the controller circuit is configured to store the data in the first plurality of GPRs, the second plurality of GPRs, or both, based on a register rule; The system of any one of claims 1 to 4.

6. the register rules include a global rule that no more than a specified number of GPRs from the second plurality of GPRs are assigned to any program; The system of claim 5.

7. the register rules include a program-specific rule that no more than a specified number of the second plurality of GPRs are assigned to a program indicated by the program-specific rule; The system of claim 5.

8. a third memory device including a third plurality of GPRs, the third memory device having fewer GPRs than the second memory device; A system according to any one of claims 1 to 7.

9. 1. A method comprising: receiving, at a compiler, program data for a program to be executed; sorting variables of the program into a first set of variables and a second set of variables, the second set of variables being expected to be accessed more frequently by the program than the first set of variables; indicating that the first set of variables are to be assigned to a first plurality of general purpose registers (GPRs) of a first memory device; indicating that the second set of variables is assigned to a second plurality of GPRs of a second memory device different from the first memory device, wherein accessing any of the first plurality of GPRs consumes more power on average than accessing any of the second plurality of GPRs, and wherein the first plurality of GPRs share a design with the second plurality of GPRs; method.

10. sorting the program variables based on the number of unassigned GPRs among the second plurality of GPRs; 10. The method of claim 9.

11. Sorting the program variables is based on comparing an expected access frequency of each of the variables to an access frequency threshold.

11. The method of claim 9 or 10.

12. adjusting the access frequency threshold based on a number of unassigned GPRs in the second plurality of GPRs. The method of claim 11.

13. and remapping at least one variable between the first plurality of GPRs and the second plurality of GPRs in response to a remapping event. The method of any one of claims 9 to 12.

14. the remapping event includes an indication of over-allocation of a GPR of the second plurality of GPRs or an indication of deallocation of a GPR of the second plurality of GPRs.

14. The method of claim 13.

15. in response to the program requesting more GPRs of the second plurality of GPRs, resorting variables of the program between the first set of variables and the second set of variables. The method of any one of claims 9 to 14.

Images