TECHNICAL FIELD

This disclosure relates generally to electronics and more particularly to processor architectures.

BACKGROUND

A register file is typically an array of processor registers. A register file can be used by various types of processors, e.g., a processor acting as a central processing unit (CPU), or one or more processors of a graphics processing unit (GPU). A register file can be used to stage data between memory and functional units of the processor. In some examples, register files are implemented using static random-access memory (SRAM) with capacity that can be flexibly allocated between one or more executing threads. Because of that capacity, register file access energy can drive a significant fraction of a system energy usage during instruction execution. Reducing the amount of energy used for register file access can reduce the overall energy used by a system.

SUMMARY

In general, one aspect of the subject matter described in this specification can be embodied in a system that comprises: a processing unit; and a register file coupled to the processing unit, the register file comprising at least a first memory structure and a second memory structure, the first memory structure having a lower access energy than the second memory structure; wherein the processing unit is configured to address the register file using a single logical namespace for both the first memory structure and the second memory structure. A system of one or more processing units can be configured to perform particular actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions.

These and other embodiments can each optionally include one or more of the following features. The system can include: a compiler that is configured to allocate, for each value of a plurality of values, the value to a register address in the single logical namespace for the register file; and a digital logic circuit that is configured to map each register address in the single logical namespace to the first memory structure or the second memory structure. The system can include a compiler that is configured to allocate, for each value of a plurality of values, the value to a register address in the single logical namespace for the register file based on the register address and a frequency of access for the value. The frequency of access for the value can be a compiler projected frequency of access. The compiler can be configured to, for each value: determine the number of times the value is read during a live range for the value; and divide the number of times the value is read by a lifetime of the live range to determine the frequency of access. The compiler can be configured to sort the values according to frequency of access into a sorted order and then allocate the values, in the sorted order, to the addresses in the namespace. The first memory structure can have a first storage capacity smaller than a second storage capacity of the second memory structure, wherein the first memory structure is implemented using a first storage technology and the second memory structure is implemented using a second storage technology, and wherein the first storage technology has a first area per unit of storage greater than a second area per unit storage for the second storage technology. The first memory structure can be implemented using an array of latches and the second memory structure is implemented using static random access memory (SRAM). The system can be configured to execute a plurality of threads and determine, at runtime, a number of register addresses per thread to map to the first and second memory structures

The details of one or more disclosed implementations are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example processing system including a processing unit, a memory unit, and a register file.

FIG. 2 is a block diagram of an example register file and a single namespace for the register file.

FIG. 3 is a block diagram of the architecture of an example graphics processing unit (GPU).

FIG. 4 is a block diagram of an example streaming multiprocessor, which can be one of the processing units of FIG. 3.

FIG. 5 is a flow diagram of an example process performed by a system of one or more processing units.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of an example processing system 100 including a processing unit 102, a memory unit 104, and a register file 106. The register file 106 includes a low energy structure 108 and a high capacity structure 110.

The processing unit is a device that carries out the instructions of a program by performing operations, e.g., arithmetic, logical, and input and output operations. The processing unit can be, e.g., a central processing unit (CPU) of a computing system, or one of many processors in a graphics processing unit (GPU). Some processing units include an arithmetic logic unit (ALU) and a control unit (CU).

The memory unit is a device configured to store digital data, e.g., instructions for execution by the processing unit. Devices suitable for storing program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

The register file is configured to store digital data. Typically, the register file is configured to perform accesses for the processing unit more quickly than the memory unit. Since register accesses can be faster than memory accesses, the register file can be used to stage data between the memory unit and functional units of the processing unit.

Reducing the amount of energy used for register file access can reduce the overall energy used by the system. In some implementations, implementing the register file using a storage technology with a low access energy causes the register file to use more area in the system or to have a lower capacity, because some storage technologies with lower access energy have a lower storage capacity per unit area. The access energy of a structure is a measure of an amount of power drawn by the structure, e.g., an average amount of power drawn over a period of time, or an amount of power drawn for one or more accesses to the structure. In some implementations, accesses to the low-energy structure consume ⅓^rd or less energy compared to the high-energy structure.

To capture the benefits of lower access energy and higher storage capacity, the register file 106 includes both the low energy structure 108 and the high capacity structure 110. For example, the low energy structure can be an array of latches and the high capacity structure can be static random access memory (SRAM).

The system can allocate more frequently accessed values to the low energy structure to reduce energy used by the system. For example, a compiler can, while compiling source code into code executable by the processing unit, use compiler allocation techniques to allocate more frequently accessed values to a first region of the single register namespace that the system is more likely to map to the low energy structure and other values to a second region of the single register namespace that the system is more likely to map to the high capacity structure. Any of various appropriate compiler allocation techniques can be used.

The processing unit is configured to address the register file using a single logical namespace for both the low energy structure and the high capacity structure. The processing unit can be configured to use the single logical namespace by virtue of instructions, e.g., stored in the memory, that when executed by the processing unit cause the processing unit to use the namespace.

In some implementations, the compiler processes source code into executable instructions and allocates register storage based on register live ranges. A register live range can begin with an operation that writes a value to the register file and end when the value is read from the register file for the last time. The compiler allocates a live range to a particular register address in the register namespace.

For each live range, the compiler can determine a metric based on the energy savings potential of mapping the live range to the low energy structure. For example, the compiler can determine the metric as the number of times a value is read during a live range divided by a lifetime of the live range. The lifetime can be measured, e.g., as a number of instructions. Other metrics are possible. The compiler can then perform register allocation using the metric with a goal of allocating live ranges with higher metrics to a region of the single register namespace that the system is likely to map onto the low energy structure, e.g., one end of the single register namespace.

At run time, when the processing unit is executing instructions generated by the compiler, the system maps register addresses from the register namespace to the low energy structure and the high capacity structure. The system can use hardware, e.g., digital logic circuitry, to perform the mapping, or the system can use the processing unit executing software, or the system can use a combination of hardware and software. The processing unit addresses the register file by a register address that the system has mapped to one of the structures.

As an example, the system can map a first continuous range of identifiers to the low energy structure and a second continuous range of identifiers, adjacent to the first continuous range, to the high capacity structure. In some other examples, the system can map even numbered register addresses to the low energy structure and odd numbered register addresses to the high capacity structure. In those examples, the compiler is configured to allocate frequently accessed values to even numbered register addresses and less frequently accessed values to odd numbered register addresses.

Using the single logical namespace for both structures can simplify the compiler, because if compilation becomes difficult the compiler can rely on a conventional allocation scheme. Any allocation will be functionally correct and register allocation becomes an energy optimization task. An allocation that assigns frequently used values into a portion of the namespace that corresponds to the high capacity structure will function properly, but will use more register file access energy than if those values were assigned to a portion of the namespace that corresponds to the low energy structure.

Using the single logical namespace can also enable a more area-efficient design compared to some other multi-level register file designs. Because the low energy structure uses the same namespace as the high capacity structure, the size of the high capacity structure can be reduced compared to other multi-level register file designs that use a separate register namespace.

FIG. 2 is a block diagram of an example register file 200 and a single namespace 206 for the register file. The system 100 of FIG. 1 can use the register file 200, for example. The register file includes a low energy structure 202 with 16 storage locations and a high capacity structure 204 with 240 storage locations. The namespace includes addresses R0 through R255.

In some implementations, the system uses the namespace to encode information about how frequently a value will be accessed. For example, the system can use compiler-projected frequency of accesses for values, or the system can use historical frequency of access information. The system can allocate a value to a location in the register file by mapping between the frequency of access for a value to an address in the namespace.

For example, the most frequently accessed value can be allocated to the location at R0 and the least frequently accessed value can be allocated to the location at R255. The hardware will try and map the location at R0 to the low energy structure and the location at R255 to the high capacity structure.

In some implementations, the compiler is configured to allocate live ranges in batches. For a given batch of live ranges, the compiler can sort the live ranges into a sorted order and then allocate the live ranges, in the sorted order, to the addresses in the namespace. For example, the compiler can begin allocating values to one end of the namespace, at R0, and then move towards the other end of the namespace. In some implementations the number of batches is one.

FIG. 3 is a block diagram of the architecture of an example graphics processing unit (GPU) 300. Although a GPU is shown, the architecture is suitable for various parallel processing tasks.

The GPU includes an interconnect 302 and 16 processing units 304a-p which can be streaming multiprocessors. The GPU includes six memory channels, and each channel includes a cache 308a-f, e.g., a level-2 cache, and a memory controller 306a-f configured to perform memory accesses, e.g., to a dynamic random access memory (DRAM) chip.

The processors are configured to perform parallel processing by executing a number of threads. The threads can be organized into execution groups called warps, which can execute together using a common physical program counter. Each thread can have its own logical program counter, and the hardware can support control-flow divergence of threads within a warp. In some implementations, all threads within a warp execute along a common control-flow path.

FIG. 4 is a block diagram of an example streaming multiprocessor 350, which can be one of the processing units 304a-p of FIG. 3. The streaming multiprocessor can include 32 single-instruction, multiple thread (SIMT) lanes 260 that can collectively issue up to 32 instructions per cycle, one from each of 32 threads. The SIMT lanes can include an arithmetic logic unit (ALU) 362, a special function unit (SFU) 364, a memory unit 366, and a texture unit 368.

The streaming multiprocessor includes a register file 352, a scheduler 358 for scheduling threads or warps or both, and shared memory 370, e.g., local scratch storage. The register file includes a low energy structure 354 and a high capacity structure 356. The streaming multiprocessor is configured to address the register file using a single logical namespace for both the low energy structure and the high capacity structure.

In some implementations, the system includes a number of physical registers which can be shared by the simultaneously running threads on the system. This is useful, for example, because a system can use a single namespace to implement a flexible register mapping scheme. The compiler allocates register live ranges to register addresses, and the compiler can use a register allocation technique to minimize or reduce the number of registers used per thread. Multiple live ranges can be allocated to the same register address as long as the live ranges do not overlap.

Then the system can determine, at runtime and after instructions have been compiled, how many entries per thread will be allocated in the low energy structure and the high capacity structure. For example, the system can map 100% of the register addresses for threads 0-31 to the low energy structure and 100% of the register addresses for threads 32-127 to the high capacity structure. As another example, the system can map 25% of each thread's registers to the low energy structure and to map 75% of each thread's registers to the high capacity structure. The system can determine the number of entries allocated per thread based on runtime information, e.g., regarding the number of warps executing and the marginal benefit from launching more warps or giving a smaller number of warps more space in the low energy structure.

FIG. 5 is a flow diagram of an example process 500 performed by a system of one or more processing units. The system can include a compiler that can be implemented in software, hardware, or both.

The system processes source code into executable instructions and, in doing so, determines a frequency of access for a value (502). The frequency of access can be based on the number of times the value is read from a register and the value's lifetime.

The system allocates a register address in a single logical namespace for a register file (504). The register file includes a first memory structure and a second memory structure, the first memory structure having a lower access energy than the second memory structure.

The system generates executable instructions for a processing unit to use the register address for the value (506). The instructions can be, e.g., assembly code or object code.

The system maps register addresses to the first and second memory structures (508). For example, in a multi-threaded system, system hardware can map the register addresses to the memory structures based on a target number of register addresses per thread.

The system executes the executable instructions, e.g., by one of the processing units, and stores the value in the register file according to both the allocated register address and the mapping between register addresses and the first and second memory structures (510).

In some implementations, the architecture and/or functionality of the various previous figures may be implemented in the context of a CPU, graphics processor, or a chipset (i.e. a group of integrated circuits designed to work and sold as a unit for performing related functions, etc.), and/or any other integrated circuit for that matter. Additionally, in some implementations, the architecture and/or functionality of the various previous figures may be implemented on a system on chip or other integrated solution.

Still yet, the architecture and/or functionality of the various previous figures may be implemented in the context of a general computer system, a circuit board system, a game console system dedicated for entertainment purposes, an application-specific system, a mobile system, and/or any other desired system, for that matter. Just by way of example, the system may include a desktop computer, lap-top computer, hand-held computer, mobile phone, personal digital assistant (PDA), peripheral (e.g. printer, etc.), any component of a computer, and/or any other type of logic. The architecture and/or functionality of the various previous figures and description may also be implemented in the form of a chip layout design, such as a semiconductor intellectual property (“IP”) core. Such an IP core may take any suitable form, including synthesizable RTL, Verilog, or VHDL, netlists, analog/digital logic files, GDS files, mask files, or a combination of one or more forms.

While this document contains many specific implementation details, these should not be construed as limitations on the scope what may be claimed, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can, in some cases, be excised from the combination, and the claimed combination may be directed to a sub combination or variation of a sub combination.