Virtual registers are mapped to architectural or physical registers according to a register map that is configurable with software. In one embodiment, only privileged software can configure the register map. In another embodiment, a portion of the register map is configurable with non-privileged software, and another portion is only configurable with privileged software. In yet another embodiment the register map is fully configurable by user software. The configurable register map provides backwards compatibility to code written for hardware-defined register mapping, while allowing flexible approaches to register mapping in code generated for a processor architecture using a software controllable register map.
|
1. A processor comprising:
a central processing unit including
a logic processor;
a plurality of architectural registers; and
a software-controllable register map configured to map virtual registers accessed by software running on the logic processor to the plurality of architectural registers.
20. A computer-readable medium having computer-executable instructions for performing a method on a processor having a software-controllable register map comprising:
defining a first register mapping array in the software-controllable register map; and
defining a second register mapping array in the software-controllable register map.
15. A method of operating a processor, the method comprising:
providing a processor with a software-controllable register map and architectural registers; and
configuring the software-controllable register map to map virtual registers in code to be executed by the processor to a first plurality of architectural registers of the processor.
14. A processor comprising:
a central processing unit including
a logic processor;
a registry having a plurality of physical registers;
a software-controllable register map configured to map virtual registers defined by non-privileged software running on the processor to architectural registers; and
a register rename map disposed between the software-controllable register map and a physical register file array, the register rename map being unaccessible by the non-privileged software.
2. The processor of
3. The processor of
5. The processor of
6. The processor of
7. The processor of
8. The processor of
9. The processor of
13. The processor of
16. The method of
17. The method of
18. The method of
re-configuring the software-controllable register map to map the virtual registers to a second plurality of architectural registers; and
executing second code on the processor.
19. A computer-readable medium having computer-executable instructions for performing the method of
21. The computer-readable medium of
executing a first portion of an application using the first mapping array; and, after defining the second register mapping array;
executing a second portion of the application.
22. The computer-readable medium of
23. The computer-readable medium of
24. The computer-readable medium of
25. The computer-readable medium of
26. The computer-readable medium of
|
Not applicable.
Not applicable.
Not applicable.
The invention relates generally to methods and apparatus for computer register memory and more particularly to mapping registers.
Computer systems use many different types of memory for storing information. Magnetic disks, optical compact disk read-only memory (“CD-ROM”), electronic ROM, and random-access memory (“RAM”) are a few examples of types of computer memory that are relatively inexpensive, in terms of the cost per bit, and capable of storing a relatively large amount of memory. However, computer systems typically have other types of memory that might not be apparent to a casual user.
A processor chip (“processor”) might have memory integrated with the logic processor to enhance operational speed. For example, the processor chip might have one or more levels of cache memory and a register file. The register file is a set of registers that is integrated with the logic processor on the central processing unit (“CPU”) section of the processor chip.
Generally, one level of memory is fed by another. For example, an application might call input that is loaded to the cache memory from the main memory (e.g. off-chip ROM or RAM), and then to the register file. Typically, each level provides faster access than the prior level, the fastest being the register files, which can work at the full internal processor speed. Unfortunately, this speed comes at a price.
Register memory has a relatively large “footprint” compared to main memory, for example, and consumes a relatively large amount of power, so the physical size of the register file is limited. Similarly, how an application can access registers is defined by the processor hardware, and usually results in a fixed relationship between registers. Processor register architectures become fixed when they are designed. This limits software to accessing a fixed number of registers in hardware. However, it is not only the number of registers that are fixed, but the methods of accessing the registers are also fixed. This contributes to an aging of the architecture over time.
This aging can arise from the evolution of software applications and how applications access registers. The growth of modular software, increasing call-chain depths, and decreasing function size are examples of how software has been changing. At the time a processor architecture is defined, certain assumptions are made about the size and number of the registers and how they will be used, such as how many bits in an instruction string will be used to identify a register address (i.e. the “register number”). Using an N-bit register number as a direct index to a register file limits software to accessing 2N registers.
Various techniques, such as register windows, have been developed for accessing other numbers of registers, but these techniques often place adders or non-power-of-two modulo operations in the logic path for physical register index generation. This can create a critical timing path issue for future hardware implementations, or impose additional pipeline stage(s) on future hardware implementations. Similarly, register access methods that attempt to access other numbers of registers with an N-bit register number system by creating multiple register files (of up to 2N registers each), for example, split integer and floating-point register files, typically require additional instruction encodings to address the different register files. Experimenting with other register models, for example to test compilers generating software to run on future hardware implementations, with a fixed set of registers and access methods can be inefficient and difficult. Similar problems or limitations can arise when simulating or emulating register models for other processor architectures, for example, when executing software generated for a “foreign” architecture. Fixed-size register windows have been used in the SPARC™ architecture and variable-size register windows have been used in the IA-64 architecture.
One microprocessor implemented a “frame pointer” register. A fixed block of general-purpose registers was stored in a block of memory starting at a location indicated by the frame pointer, instead of putting the block of registers on-chip. The frame pointer mapped all register references to a block of memory addresses. This was a degenerate case of a register map because the frame pointer contained only one entry, instead of a separate map entry for each register. The frame pointer technique partially addressed the problems of addressing a fixed number of registers in hardware and N-bit register numbers limiting software to 2N registers, but left other problems unresolved. Unfortunately, a frame pointer technique would probably provide unacceptably poor performance in current microprocessors, where memory access is typically orders of magnitude slower than on-chip register access.
Other processor architectures, such as the scalable processor architecture (“SPARC”™) version 8 (“V8”), IA-64, IA-32, and 680X0, have addressed the problem of being limited to 2N registers when using N-bit direct index register numbers by creating separate namespaces for different types of register, for example, integer/general purpose and floating-point name spaces. Given N-bit register number fields in instructions, more than one set of 2N registers can be addressed by restricting register number fields in each instruction to only address one set of 2N registers (i.e. only one register name space at a time). However, this approach still suffers from architecture aging, not allowing applications to optimize register access, and requiring additional instruction encodings to address all the register namespaces.
The hardware technique of register re-naming, as is typically used in out-of-order processor implementations, partially addresses the problems of addressing a fixed number of registers in hardware and N-bit register numbers limiting software to 2N registers, but leaves other problems unresolved. Register re-naming is a hardware technique that is invisible to software and involves use of a register map. SPARC64™, PA-8000™, MIPS R10000™ and PENTIUM™ processors include examples of processors using hardware register re-naming.
In summary, most processor architectures have provided a fixed-size array of general-purpose registers, accessible by a single access method in instructions, namely, direct index into the register array. At least one architecture has added an additional rotating register method of accessing those registers. However, even using rotating registers leaves several problems unresolved.
A processor architecture has a register map that is controllable with software. In one embodiment, the register map is controllable with user (application or non-privileged) software. In another embodiment, some or all of the register map is only controllable with privileged software, such as the operating system.
A register map that is programmable through software, rather than fixed in hardware, provides a flexible register architecture(s). The programmable register map can support various access methods and can accommodate new register organizations as software evolves. Compilers can experiment with new register organizations on existing hardware, and register-access methods can be optimized on a per-application basis. Similarly, a large physical register file can be utilized in a flexible manner and can focus on particular categories of performance needs, e.g. floating-point vs. JAVA™ execution.
The chip 10 interfaces with other functional blocks of a computer system, such as main memory 34. Main memory is generally slower but less expensive than registers. The optimum number of registers is not fixed for all applications, and it is generally desirable to limit the number of physical registers to the anticipated maximum number needed for an application. However, it is difficult to anticipate what will be needed as application software evolves. For example, application call depth is growing, breaking prior assumptions about optimal register architecture that led to register windows. While register windows appeared to be a good solution at the time, and are still desirable for many applications, in other instances an undesirable number of runtime register spills/fills to memory may occur. Similarly, application function size is shrinking, causing 16-register windows to be used inefficiently in some applications.
Embodiments of the present invention allow a flexible approach to register mapping. In some instances, emulation of a prior hardware-based register mapping technique is achieved. Such emulation allows code written for a processor with hardware-based register mapping to run on later processors with software-controllable register mapping. Register windows are an example of a prior hardware-based register mapping technique that may be emulated with software-controllable register mapping.
To emulate register windows using the register configuration shown in
For each block of 16 architectural registers (referred to in this section as an “architectural register window block” or “ARWB”), the following information is kept:
Given the data structures in
#
va[] is the 32-entry Register Map array
#
(maps virtual register #s to architectural register #s)
#
ap[] is the 256-entry Architectural register map array
#
(maps architectural register #s to physical register #s)
#
p[] is array of physical registers
# Take SAVE operands from registers in the “old” window.
if (instruction.i = 1)
then result <-- p[ap[va[instruction.rs1]]]
+ p[ap[va[instruction.rs2]]];
else result <-- p[ap[va[instruction.rs1]]] +
sign_extend(instruction.simm13);
endif
# Get the index to the next register window (block of
# 16 architectural registers). Use the most significant 4 bits
# of one of the “out” registers (8-15) to generate the index
# into the SR_next_save_ARWB array.
next_ARWB <-- SR_next_save_ARWB[va[8]<7:4>];
# If the next register window (block of 16 architectural registers)
# is already in use, save them to memory.
if(SR_ARWB_is_in_use[next_ARWB] = 1)
then
{ spill the 16 architectural registers indicated by
next_ARWB to a safe location in memory }
endif
# Update the 8 ″in″ register mapping from the old ″out″
register maps.
# (if register windows are truly aligned on 16-register boundaries
# in the architectural register file, then only the most significant
# 4 bits of each ″in″ register mapping would need to be updated).
va[31] <-- va[15];
va[30] <-- va[14];
va[29] <-- va[13];
va[28] <-- va[12];
va[27] <-- va[11];
va[26] <-- va[10];
va[25] <-- va[9];
va[24] <-- va[8];
# Update the most signficant 4 bits of ″local″ (16-23) and
# ″out″ (8-15) register maps, from the starting register number
# of the new block of architectural registers.
va[23]<7:4> <-- next_ARWB;
va[22]<7:4> <-- next_ARWB;
va[21]<7:4> <-- next_ARWB;
va[20]<7:4> <-- next_ARWB;
va[19]<7:4> <-- next_ARWB;
va[18]<7:4> <-- next_ARWB;
va[17]<7:4> <-- next_ARWB;
va[16]<7:4> <-- next_ARWB;
va[15]<7:4> <-- next_ARWB;
va[14]<7:4> <-- next_ARWB;
va[13]<7:4> <-- next_ARWB;
va[19]<7:4> <-- next_ARWB;
va[12]<7:4> <-- next_ARWB;
va[11]<7:4> <-- next_ARWB;
va[10]<7:4> <-- next_ARWB;
va[9]<7:4> <-- next_ARWB;
va[8]<7:4> <-- next_ARWB;
# Mark the ″window block″ as ″in use″
SR_ARWB_is_in_use[next_ARWB] <-- 1;
# Set the result of the SAVE instruction in the destination
# register of the SAVE (which is relative to the new window).
if (instruction.rd != 0)
then p[ap[va[instruction.rd]]] <-- result;
endif
Note that software access privileges are not required to be uniform across all architectural registers. For example, some architectural registers may be read-only to, or not mappable at all by, nonprivileged software. In those cases, privileged software could make privileged information completely inaccessible to, accessible on a read-only basis to, or fully accessible (readable and writable) to nonprivileged software. One possible application of this is that privileged software could retain key privileged information in privileged architectural registers while nonprivileged software executes, without the potentially time-consuming operations (required in conventional register schemes) of saving and restoring that information to and from memory. Privileged software would only have to save the mapping to those registers, which itself could be saved in architectural register(s) and would not necessarily have to be saved in memory.
A TAGS field could carry information such as a “register dirty” bit (meaning that the register had been modified since the dirty bit was last set to zero), a speculative-load exception bit (which would indicated that an exception would have occurred on the last speculative load that used the register as a destination register), and/or register condition code tags for access by branch-on-register-value operations. Live and PrevP might be used in an implementation using a conservative register renaming strategy. During instruction decode, the virtual register numbers in an instruction are mapped to physical registers via the current register map and RRM, if any. While the instruction in the cache retains reference to the original virtual register numbers, the corresponding instruction in the processor's execution pipeline would refer to the physical register number, with no notion of the original virtual register number being retained in the pipeline.
In an implementation of a two-level map (ref.
One such optimization would be to create a 32-entry (generally (log2(nAR))rup) register map cache (“RMC”) in hardware, invisible to software, that contains the current physical register number to which each virtual register is currently mapped. As each instruction is decoded, the decoder would directly read the current virtual-to-physical translation for each virtual register number from the RMC, without doing a two-level lookup through the user register map and the RRM. The RMC, or the applicable portion of it, would be updated by hardware when the register map or RRM is updated.
A full register map in this example comprises 256 bits (shown in FIG. 4A and
It is anticipated that the time required to do a virtual-to-architectural register number mapping when decoding each instruction will be less for register mapping according to at least some embodiments of the present invention than for traditional register windowing, such as in SPARC™ version 9 (“V9”). In SPARC™ V9, each register number reference is relative to the CWP, which in most implementations means that virtual register numbers must pass through at least an adder and a modulo operation, and possibly two of each, to translate a windowed register number to an architectural register number.
A processor architecture that includes register mapping could guarantee that a minimum number of architectural registers, e.g. 64, would be available in all its implementations. Portable software would map a maximum of 64 architectural registers. An implementation with a larger architectural register file could be built, up to the limits imposed by the width of a register map entry. Although portable software would not access the additional registers, kernel code, dynamically linked libraries, JIT-compiled, and dynamically compiled/translated code could use them.
In a further embodiment, the register map could be used to map virtual register numbers to registers on other processor cores, which might be on the same die or on a different die. Such accesses would probably incur longer latency than local accesses, and there would probably be a practical limit to the number of processor register sets that could be accessed.
Privileged (“kernel”) code could have its own integer register map, or part of one, such as registers 1-7. An automatic switch to the kernel register map could occur upon a trap. The kernel register map might, for example, map virtual registers 1 through 7 into a different set of architectural registers than does the nonprivileged register map. The switch could implement a globals-per-trap-level feature that is desired by kernel software designers.
On a processor architecture with multiple register namespaces, such as separate integer and floating-point register namespaces, floating-point registers may be mapped with a floating-point register map parallel to the integer register map. The floating-point and integer registers could map into the same or separate underlying architectural register files. If they map into the same architectural register file, then integer instructions could access floating-point values and vice versa. Even if integer and floating-point registers map to different architectural register files, it might be possible to allow each to map in parts of the other's register file. For example, the most significant bit of each register map entry might be used to select the register file. However, in such a case, access by an integer instruction to a floating-point register may incur additional cycles of access latency.
A separate map might be used for each precision of floating-point registers. That is, single-, double-, and quad-precision registers would all be mapped into the same architectural register file, but the different precisions of registers would no longer (at least in a SPARC™ implementation) need to be overlapped. In order to be compatible when executing SPARC™ V9 code, all floating-point registers could be mapped in the overlapping manner specified by SPARC™ V9. Similarly, a portion of the floating-point registers could be mapped to support unaligned FORTRAN doubles, or a portion of them could be overlapped for special code that takes advantage of the overlap.
Software-controllable register mapping, according to embodiments of the present invention, are compatible with several other register organization techniques, such as group mapping, individual mapping instructions, smaller fixed-size windows, variable-size register windows, register dirty bits, stack last-in-first-out registers, queued first-in-first-out registers, and N-bit register identifier techniques, where N can be adapted to a particular register architecture. Software-controllable register mapping allows use of various types of instructions to alter the mapping. In some instances, the processor can execute a sequence of instructions written for a different processor and register access method, or new map-altering instructions can be added.
A processor with a software-controllable register map(s) is provided (step 501). The register map(s) is configured to map virtual registers in code, i.e. software such as non-privileged user code or privileged code, that is intended to be executed by the processor to access architectural registers of the processor (step 503). The code is then executed by the processor (step 505). In some instances, the code may be self-configuring, that is, it may contain computer-readable instructions for configuring the register map(s) before executing subsequent instructions.
In a further embodiment, after executing the code in step 505, the register map(s) is configured to a second configuration (mapping) of virtual registers to architectural registers (step 507) and a second block of code is executed by the processor (step 509). In other words, the register mapping is different between the execution of code in step 505 and the execution of code in step 509. Such re-configuring may occur more times, and may be structured as a loop back to a configuration step.
Instructions for performing the method illustrated in
While the invention has been described in conjunction with several specific embodiments, it is evident to those skilled in the art that many further alternatives, modifications, and variations will be apparent in light of the foregoing description. Thus, the invention described herein is intended to embrace all such alternatives, modifications, applications, and variations as may fall within the spirit and scope of the following claims.
Patent | Priority | Assignee | Title |
10061699, | Aug 05 2008 | Micron Technology, Inc. | Multiple data channel memory module architecture |
10430190, | Jun 07 2012 | Micron Technology, Inc | Systems and methods for selectively controlling multithreaded execution of executable code segments |
10949347, | Aug 05 2008 | Micron Technology, Inc. | Multiple data channel memory module architecture |
11106592, | Jan 04 2008 | Micron Technology, Inc. | Microprocessor architecture having alternative memory access paths |
11550719, | Aug 05 2008 | Micron Technology, Inc. | Multiple data channel memory module architecture |
7363614, | Jan 21 2003 | HYDROGEN TECHNOLOGY APPLICATIONS, INC | Automatic test program generation method |
7631167, | Mar 02 2006 | Meta Platforms, Inc | System for SIMD-oriented management of register maps for map-based indirect register-file access |
8423745, | Nov 16 2009 | Micron Technology, Inc | Systems and methods for mapping a neighborhood of data to general registers of a processing element |
8443147, | Aug 05 2008 | Micron Technology, Inc | Memory interleave for heterogeneous computing |
8561037, | Aug 29 2007 | Micron Technology, Inc | Compiler for generating an executable comprising instructions for a plurality of different instruction sets |
8578136, | Jun 15 2010 | ARM Limited | Apparatus and method for mapping architectural registers to physical registers |
9015399, | Aug 05 2008 | Micron Technology, Inc | Multiple data channel memory module architecture |
9311088, | Jun 15 2010 | ARM Limited | Apparatus and method for mapping architectural registers to physical registers |
9449659, | Aug 05 2008 | Micron Technology, Inc | Multiple data channel memory module architecture |
9710384, | Jan 04 2008 | Micron Technology, Inc | Microprocessor architecture having alternative memory access paths |
9824010, | Aug 05 2008 | Micron Technology, Inc | Multiple data channel memory module architecture |
Patent | Priority | Assignee | Title |
20030074545, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Apr 03 2002 | WEAVER, DAVID L | Sun Microsystems, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 012794 | /0763 | |
Apr 09 2002 | Sun Microsystems, Inc. | (assignment on the face of the patent) | / | |||
Feb 12 2010 | ORACLE USA, INC | Oracle America, Inc | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 037280 | /0232 | |
Feb 12 2010 | Sun Microsystems, Inc | Oracle America, Inc | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 037280 | /0232 | |
Feb 12 2010 | Oracle America, Inc | Oracle America, Inc | MERGER AND CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 037280 | /0232 |
Date | Maintenance Fee Events |
Nov 18 2009 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Nov 20 2013 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Dec 07 2017 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Jun 20 2009 | 4 years fee payment window open |
Dec 20 2009 | 6 months grace period start (w surcharge) |
Jun 20 2010 | patent expiry (for year 4) |
Jun 20 2012 | 2 years to revive unintentionally abandoned end. (for year 4) |
Jun 20 2013 | 8 years fee payment window open |
Dec 20 2013 | 6 months grace period start (w surcharge) |
Jun 20 2014 | patent expiry (for year 8) |
Jun 20 2016 | 2 years to revive unintentionally abandoned end. (for year 8) |
Jun 20 2017 | 12 years fee payment window open |
Dec 20 2017 | 6 months grace period start (w surcharge) |
Jun 20 2018 | patent expiry (for year 12) |
Jun 20 2020 | 2 years to revive unintentionally abandoned end. (for year 12) |