Electrical computers and digital processing systems: processing – Processing architecture – Microprocessor or multichip or multimodule processor having...
Reexamination Certificate
2001-02-16
2002-05-21
Coleman, Eric (Department: 2183)
Electrical computers and digital processing systems: processing
Processing architecture
Microprocessor or multichip or multimodule processor having...
C711S210000
Reexamination Certificate
active
06393546
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention is related to the field of processors and, more particularly, to register renaming mechanisms within processors.
2. Description of the Related Art
Superscalar processors attempt to achieve high performance by dispatching and executing multiple instructions per clock cycle, and by operating at the shortest possible clock cycle time consistent with the design. To the extent that a given processor is successful at dispatching and/or executing multiple instructions per clock cycle, high performance may be realized.
One technique often employed by processors to increase the number of instructions which may be executed concurrently is speculative execution (e.g. executing instructions out of order with respect to the order of execution indicated by the program or executing instructions subsequent to predicted branches). Often, instructions which are immediately subsequent to a particular instruction are dependent upon that particular instruction (i.e. the result of the particular instruction is used by the immediately subsequent instructions). Hence, the immediately subsequent instructions may not be executable concurrently with the particular instruction. However, instructions which are farther subsequent to the particular instruction in program order may not have any dependency upon the particular instruction and may therefore execute concurrently with the particular instruction. Still further, speculative execution of instructions subsequent to mispredicted branches may increase the number of instructions executed concurrently if the branch is predicted correctly.
Out of order execution gives rise to another type of dependency, often referred to as an “antidependency”. Generally, antidependencies occur if an instruction subsequent to a particular instruction updates a register which is either accessed (read) or updated (written) by the particular instruction. The particular instruction must read or write the register prior to the subsequent instruction writing the register for proper operation of the program. Generally, an instruction may have one or more source operands (which are input values to be operated upon by the instructions) which may be stored in memory or in registers. An instruction may also have one or more destinations (which are locations for storing results of executing the instruction) which may also be stored in memory or in registers.
A technique for removing antidependencies between source and destination registers of instructions, and thereby allowing increased out of order execution, is register renaming. In register renaming, a pool of “rename registers” are implemented by the processor. The pool of rename registers are greater in number than (i) the registers defined by the instruction set architecture employed by the processor (the “architected registers”) and (ii) the registers employed for temporary use, such as by microcode routines (the “temporary registers”). Together, the architected registers and temporary registers are referred to as the “logical registers”. The destination register for a particular instruction (i.e. the logical register written with the execution result of the instruction) is “renamed” by assigning one of the rename registers to the logical register. The value of the logical register prior to execution of the particular instruction remains stored in the rename register previously assigned to the logical register. If a previous instruction reads the logical register, the previously assigned rename register is read. If a previous instruction writes the logical register, the previously assigned rename register is written. Accordingly, the rename registers may be updated in any order.
Register renaming may also allow speculative update of registers due to instruction execution subsequent to a predicted branch instruction. Previous renames may be maintained until the branch instruction is resolved. If the branch instruction is mispredicted, the previous renames may be used to recover the state of the processor at the mispredicted branch instruction.
In many instruction set architectures, a variety of architected registers are provided for storing instruction results of varying types. For example, integer, floating point, multimedia, and condition code registers may be defined. Integer registers are employed for storing integer values (i.e. whole number values represented by the magnitude of the value stored in the registers). Floating point registers are employed for storing the floating point values (i.e. numbers represented by a sign, exponent, and significand stored in the register). Multimedia registers are used for storing multimedia values (e.g. packed integer or floating values representing audio and video information, operated upon in a single instruction, multiple data (SIMD) fashion). Finally, condition code registers store values which indicate the result of a particular manipulation (e.g. zero, greater than or less than zero, carry out) or comparison (e.g. equal, greater than, less than). Condition codes may also be referred to herein as “flags”.
Each of the various types of registers may have a different size than the others. For example, in the x86 instruction set architecture, floating point registers are 80 bits wide, multimedia registers are 64 bits wide, integer registers are 32 bits wide (and subdivided into independently addressable portions), and the condition codes are stored in an EFLAGS register but comprise 6 bits. Accordingly, processors typically rename each register type separately with register renames of the corresponding size. Unfortunately, rename registers of a particular type may be idle if instructions manipulating that type are not being executed. For example, floating point renames are idle if floating point instructions are not being executed. The total amount of available rename register space may therefore by inefficiently used much of the time.
Furthermore, in the x86 instruction set architecture many integer instructions update both a destination and the condition codes. Therefore, multiple rename registers may need to be assigned to each instruction. Register rename logic complexity may therefore be significant. Accordingly, a more efficient and simpler register rename scheme is desired.
SUMMARY OF THE INVENTION
A register renaming apparatus, according to one embodiment, includes one or more rename registers (referred to herein as physical registers) which may be assigned to store any of: a floating point value, a multimedia value, an integer value and corresponding condition codes, or condition codes only. For physical register assignment, an instruction is classified as being floating point (e.g. having a floating point register as a destination), multimedia (e.g. having a multimedia register as a destination), integer (e.g. having an integer register and the flags register as destinations), or a flags-only (e.g. having the flags register as a destination). The classification of the instruction defines which lookahead register state is updated (floating point, integer, flags, etc.), but the physical register can be selected from the one or more physical registers for any of the instruction types. Advantageously, determining which physical register to select may be simplified over an implementation which employs separate sets of physical registers for each data type. For example, part of the register renaming logic is to determine if enough physical registers are free for assignment to the instructions being selected for dispatch. In an implementation employing different physical registers for different data types, this determination includes determining the data type of each instruction (to determine how many physical registers of each type are needed). Instead, the register renaming apparatus described below considers the number of instructions selected for dispatch and the number of free physical registers.
Additionally, an embodiment of the register renaming apparatus described herein may make more efficient use of th
Keller James B.
Witt David B.
Coleman Eric
Conley Rose & Tayon PC
Merkel Lawrence J.
LandOfFree
Physical rename register for efficiently storing floating... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Physical rename register for efficiently storing floating..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Physical rename register for efficiently storing floating... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2823729