Patent Application
20090282220
Embodiments of the present invention relate generally to microprocessors. More particularly, embodiments of the present invention relate to instruction set architectures for microprocessors.
There is an expanding need for economical, high performance microprocessors, especially for deeply embedded applications such as microcontroller applications. As a result, microprocessor customers require efficient solutions that can be quickly and effectively integrated into products. Moreover, designers and microprocessor customers continue to demand lower power consumption, and have recently focused on environmentally friendly microprocessor-powered devices.
One way to achieve these requirements is to revise an existing instruction set (also known herein as an Instruction Set Architecture (ISA)) into a new instruction set having a smaller code footprint. The smaller code footprint generally translates into lower power consumption per executed task. Smaller instruction sizes may also lead to higher performance. One reason for this improved efficiency is the lower number of memory accesses required to fetch the smaller instruction. Additional benefits may be derived by basing a new ISA on a combination of smaller bit-width and larger bit-width instructions derived from an ISA having a larger bit-width.
Embodiments of the present invention relate to re-encoding instruction set architectures to be used with a microprocessor, and new instructions resulting therefrom. According to an embodiment, a larger bit-width instruction set is re-encoded to a smaller bit-width instruction set or an instruction set having a combination of smaller bit-width instructions and larger bit-width instructions. In embodiments, the smaller bit-width instruction set retains assembly-level compatibility with the larger bit-width instruction set from which it is derived and has different types of instructions added. Moreover, the new smaller bit-width instruction set or combined smaller and larger bit-width instruction sets may be more efficient and have higher performance than the larger bit-width instruction set from which it was re-encoded.
In an embodiment, several new smaller bit-width instructions are added to the new instruction set, including: Compact Branch on Equal to Zero (BEQZC), Compact Branch on not Equal to Zero (BNEZC), Jump and Link Exchange (JALX), Compact Jump Register (JRC), Load Register Pair (LRP), Load Word Multiple (LWM), Store Register Pair (SRP) and StoreWord Multiple (SWM).
Embodiments of the invention are described with reference to the accompanying drawings. In the drawings, like reference numbers may indicate identical or functionally similar elements. The drawing in which an element first appears is generally indicated by the left-most digit in the corresponding reference number.
While the present invention is described herein with reference to illustrative embodiments for particular applications, it should be understood that the invention is not limited thereto. Those skilled in the art with access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which the invention would be of significant utility. The following sections describe an instruction set architecture according to an embodiment of the present invention.
a. Assembly Level Compatibility
b. Special Event ISA Mode Selection
a. Re-encoded Branch and Jump Instructions
b. Encoded Fields Based on Statistical Analysis
c. Delay Slots
a. Principle Opcode Organization
b. Major Opcodes
a. New 16-Bit Instructions Re-Encoded from 32-Bit Instructions
b. New 32-Bit Instructions Re-Encoded from Legacy 32-Bit Instructions
c. 16-Bit User Defined Instructions (UDIs)
d. Unification of ASEs
e. New ISA Instructions
Embodiments described herein relate to an ISA comprising instructions to be executed on a microprocessor and a microprocessor on which the instruction of the ISA can be executed. Some embodiments described herein relate to an ISA that resulted from re-encoding a larger bit-width ISA to a combined smaller and larger bit-width ISA. In one embodiment, the larger bit-width ISA is MIPS32 available from MIPS, INC. of Mountain View, Calif., the re-encoded smaller bit-width ISA is the MicroMIPS 16-bit instruction set also available from MIPS, INC., and the re-encoded larger bit-width ISA is the MicroMIPS 32-bit instruction set, also available from MIPS, INC.
In another embodiment, the larger bit-width architecture may be re-encoded into an improved architecture with the same bit-width or a combination of same bit-width instructions and smaller bit-width instructions. In one embodiment, the re-encoded larger-bit width instruction set is encoded to a same size bit-width ISA, in such a fashion as to be compatible with, and complementary to, a re-encoded smaller bit-width instruction set of the type discussed herein. Embodiments of the re-encoded larger bit width instruction set may be termed as “enhanced,” and may contain various features, discussed below, that allow the new instruction set to be implemented in a parallel mode, where both instruction sets may be utilized on a processor. Re-encoded instruction sets described herein also work in a standalone mode, where only one instruction set is active at a time.
a. Assembly Level Compatibility
Embodiments described herein retain assembly-level compatibility after re-encoding from the larger bit-width to the smaller bit-width or combined bit width ISAs. To accomplish this, in one embodiment, post-re-encoding assembly language instruction set mnemonics are the same as the instructions from which they are derived. Maintaining assembly level compatibility allows instruction set assembly source code, using the larger bit-width ISA, to be compiled with assembly source code using the smaller bit-width ISA. In other words, an assembler targeting the new ISA embodiments of the present invention can also assemble legacy ISAs from which embodiments of the present invention were derived.
In an embodiment, the assembler determines which ISA to use to process a particular instruction. For example, to differentiate between instructions of different bit-width ISAs, in an embodiment, the opcode mnemonic is extended with a suffix corresponding to the different size. For example, in one embodiment, a “16” or “32” suffix is placed at the end of the instruction before the first “.”, if one exists, to distinguish between 16-bit and 32-bit encoded instructions. For example, in one embodiment, “ADD16” refers to a 16-bit version of an ADD instruction, and “ADD32” refers to a 32-bit version of the ADD instruction. As would be known to one skilled in the art, other suffices may be used.
Other embodiments do not use suffix designations of instruction size. In such embodiments, the bit-width suffices may be omitted. In an embodiment, the assembler will look at the values in a command's register and immediate fields and decide whether a larger or smaller bit-width command is appropriate. Depending upon assembler settings, the assembler may automatically choose the smallest available instruction size when processing a particular instruction.
b. Special Event ISA Mode Selection
In another embodiment, ISA selection occurs in one of the following circumstances: exceptions, interrupts and power-on events. In such an embodiment, a handler that is handling the special event specifies the ISA. For example, on power-on a power-on handler can specify the ISA. Likewise, an interrupt or exception handler can specify the ISA.
Embodiments having new ISA instructions are be described below, as well as embodiments with re-encoded instructions. Several general principles have been used to develop these instructions, and these are explained below.
a. Re-Encoded Branch and Jump Instructions
In one embodiment, the re-encoded smaller bit-width ISA supports smaller branch target addresses, providing enhanced flexibility. For example, in one embodiment, a 32-bit branch instruction re-encoded as a 16-bit branch instruction supports 16-bit-aligned branch target addresses.
In another example, because the offset field size of the 32-bit re-encoded branch instruction remains identical to the legacy 32-bit re-encoded instructions, the branch range may be smaller. In further embodiments, the jump instructions J, JAL and JALX support the entire jump range by supporting 32-bit aligned target addresses.
b. Encoded Fields Based on Statistical Analysis
The term ‘immediate field’ as used herein and is well known in the art. In embodiments, the immediate field can include the address offset field for branches, load/store instructions, and target fields. In embodiments, the immediate field width and position within the instruction encoding is instruction dependent. In an embodiment, the immediate field of an instruction is split into several fields that need not be adjacent.
In an embodiment, use of certain register and immediate values for ISA instructions and macros, may convey a higher level of performance than other values. Embodiments described herein use this principle to enhance the performance of instructions. For example, to achieve such performance, in one embodiment, analysis of the statistical frequency of values used in register and immediate fields over a period of usage of an ISA is performed. Based on this analysis, embodiments, instead of using unmodified register or immediate values, encode the values to link the highest performance register and immediate values to the most commonly used values, as determined by the statistical analysis above.
To assist in the re-encoding of an ISA as described herein, the above encoding approach also may allow a reduction in the required size of register and immediate fields, because certain less common values may be omitted from encoding. For example, encoded register and immediate values may be encoded into a shorter bit-width than the original value, e.g., “1001” may encode to “10.” When recoding larger bit-width instruction sets to smaller bit-width ISAs, less frequently used values may be omitted from the new list.
c. Delay Slots
In a pipelined architecture, a delay slot is filled by an instruction that is executed without the effects of a preceding instruction, for example a single instruction located immediately after a branch instruction. A delay slot instruction will execute even if the preceding branch is taken. Delay slots may increase efficiency, but are not efficient for all applications. For example, for certain applications (e.g., high performance applications), not using delay slots has little, if any impact on making the resulting code smaller. At times, a compiler attempting to fill a delay slot cannot find a useful instruction. In such cases, a no operation (NOP) instruction is placed in the delay slot, which may add to a program's footprint and decrease performance efficiency.
Embodiments described herein offer a developer a choice when using of delay slots. Given this choice, a developer may choose how best to use delay slots so as to maximize desired results, e.g., code size, performance efficiency, and ease of development. In an embodiment, certain instructions described herein have two versions—exemplary instructions are the jump of branch instructions. Such instructions have one version with a delay slot and one version without a delay slot. In an embodiment, which version to use is software selected when the instruction is coded. In another embodiment, which version to use is selected by the developer (as with the selection of ADD16 or ADD32 described above). In yet another embodiment, which version to use is selected automatically by the assembler (as described above). This feature in such embodiments may also help maintain compatibility with legacy hardware processors.
In another embodiment, the size of a delay slot is fixed. Embodiments herein involve an instruction set with two sizes of instructions (e.g., 16 bit and 32 bit). A fixed-width delay slot allows a designer to define a delay slot instruction so that the size will always be a certain size, e.g., a larger bit-width slot or shorter bit-width slot. This delay slot selection allows a designer to broadly pursue different development goals. To minimize code footprint, a uniformly smaller bit-width delay slot might be selected. However, this may result in a higher likelihood that the smaller slots might not be filled. In contrast, to maximize the potential performance benefit of the delay slot, a larger bit-width slot may be selected. This choice, however, may increase code footprint.
In an embodiment, delay slot width may be selected by the designer as either a larger bit-width or smaller bit-width at the time the instruction is coded. This is similar to the embodiments described herein that allow for manual selection of instruction bit-width (ADD16 or ADD32). As with the fixed bit-width selection described above, this delay slot selection allows a designer to pursue different development goals. With this approach however, the bit-width choice may be made for each command, as opposed to the system overall.
As would be appreciated by one skilled in the art, approaches to delay slots described above may be applied to any instruction that is capable of using delay slots.
In an embodiment the new ISA comprises instructions having at least two different bit widths. For example, an ISA according to an embodiment includes instructions that have 16-bit and 32-bit widths. Although embodiments of the new ISA described herein describe two instruction sets that operate in a complementary fashion, the teachings herein would apply to any number of ISA instruction sets.
In an embodiment, instructions have opcodes comprising a major, and in some cases a minor opcode. The major opcode has a fixed width, while the minor opcode has a width that depends on the instruction, including widths large enough to access an entire register set. For example, in one embodiment, the MOVE instruction has a 5-bit minor opcode, and may reach the entire register set. For example, in one embodiment, encoding comprises 16-bit and 32-bit wide instructions, both having a 6-bit major opcode right aligned within the instruction encoding, followed by a variable width minor opcode.
The major opcode is the same for both the larger bit-width and smaller bit-width instruction sets. For example, in one embodiment, encoding comprises 16-bit and 32-bit wide instructions, both having a 6-bit major opcode right aligned within the instruction encoding, followed by a variable width minor opcode.
a. Principle Opcode Organization
In an embodiment, 16-bit instructions may use larger bit-widths registers 220, including widths large enough to access an entire register set. For example, in one embodiment, a 16-bit MOVE instruction has 5-bit register fields. Use of 5-bit register fields allows the 16-bit MOVE instructions to access any register in a register set having 32 registers. In an embodiment, 16-bit instructions can further include one or more immediate fields 230. Other optional instruction specific fields 240 may be to the left of the opcode 260 or 250. In an exemplary embodiment, 16-bit instructions can have 0 to 1 left aligned register fields 220. An opcode field comprises a major opcode 260 and, in some cases, a minor opcode field 250 appears to the right of any other fields 240.
b. Major Opcodes Table 1 provides a listing of instructions formats for an ISA according to an embodiment. As can be seen from Table 1, instructions in the exemplary ISA have 16 or 32 bits. Nomenclature for the instruction formats appearing in Table 1 are based on the number of register fields and immediate field size for the instruction format. That is, the instruction names have the format R<x>I<y>. Where <x> is the number of register in the instruction format and <y> is the immediate field size. For example, an instruction based on the format R2I16 has two register fields and a 16-bit immediate field.
In an embodiment, new instructions are added to the re-encoded legacy instructions as part of an ISA according to an embodiment. These new instructions are designed to reduce code size. Tables 2-5 illustrate formats for the re-encoded instructions for an ISA according to an embodiment. Tables 2 and 3 provide instruction formats for instruction 32-bit instructions of a legacy ISA re-encoded as 16-bit instructions in an ISA according to an embodiment. In an embodiment, selection of which legacy 32-bit ISA instructions to re-encode as 16-bit new ISA instructions is based on a statistical analysis of legacy code to determine more frequently used instructions. An exemplary set of such instructions is provided in Tables 2 and 3. Table 3 provides examples of instruction specific register encoding or immediate field size encoding described above. Table 4 provides instruction formats for 32-bit instructions in the new ISA re-encoded from 32-bit instructions in a legacy ISA according to an embodiment. Table 5 provides instruction formats for 32-bit user defined instructions (UDIs) according to an embodiment.
Tables 2-5 provide in order from the most significant bits formats for an exemplary ISA re-encoding according to an embodiment—defining the register fields, immediate fields, other fields, empty fields, minor opcode field to the major opcode field. As described above, most 32-bit re-encoded instructions have 5-bit wide register fields. In an embodiment, 5-bit wide register fields use linear encoding (r0=‘00000’, r1=‘00001’, etc.). Instructions of 16-bit width can have different size register fields, for example, 3- and 5-bit wide register fields. Register field widths for 16-bit instructions according to an embodiment, are provided in tables 2-5. The ‘other fields’ are defined by the respective column and the order of these fields in the instruction encoding is defined by the order in the tables.
a. New 16-Bit Instructions Re-Encoded from 32-Bit Instructions
As discussed above, in embodiments described herein, a larger bit-width ISA may be re-encoded to a smaller bit-width ISA or a combined smaller and larger bit-width ISA. In one embodiment, to enable the larger ISA to be re-encoded into a smaller ISA, the smaller bit-width ISA instructions have smaller register and immediate fields. In one embodiment, as described above, this reduction may be accomplished by encoding frequently used registers and immediate values.
In one embodiment, an ISA uses both an enhanced 32-bit instruction set and a narrower re-encoded 16-bit instruction set. The re-encoded 16-bit instructions have smaller register and immediate fields, and the reduction in size is accomplished by encoding frequently used registers and immediate values.
For example, listed in table 2 below, re-encodings for frequently used legacy instructions are shown with smaller register and immediate fields corresponding to frequently used registers and immediate values.
Because the instruction MOVE is a very frequently used instruction, in an embodiment, as described above, the MOVE instruction supports full 5-bit unrestricted register fields so as to reach all available registers, as well as to maximize efficiency.
In an embodiment, there are two variants of load word (LW) and store word (SW) instructions. One variant uses the SP register in state registers 428 (see
In an embodiment, there are two variants of the ADDIU instruction. The first variant of the ADDIU instruction has a larger immediate field and only one register field. In the first variant of the ADDRU instruction, the register field represents a source as well as a destination. The second variant the ADDIU instruction has a smaller immediate field, but two register fields.
16 bit instructions may sometimes result in misalignment. To address this misalignment and to align instructions on a 32-bit boundary in specific cases, a 16-bit NOP instruction is provided in an embodiment described herein. The 16-bit NOP instruction may reduce code size as well.
The NOP instruction is not shown in the table because in the exemplary embodiment, the NOP instruction is implemented as macro. For example, in one embodiment, the 16-bit NOP instruction is implemented as “MOVE16 r0, r0.”
In an embodiment, the compact instruction JRC is preferred over the JR instruction when the jump delay slot after JR cannot be filled. Because the JRC instruction may execute as fast as JR with a NOP in the delay slot, the JR instruction should be used if the delay slot can be filled.
Also, in an embodiment, the breakpoint instructions BREAK and SDBBP include a 16-bit variant. This allows a breakpoint to be inserted at any instruction address without overwriting more than a single instruction.
b. New 32-Bit Instructions Re-Encoded from Legacy 32-Bit Instructions
In an embodiment of the new ISA, legacy 32-bit instructions are re-encoded into new 32-bit instructions. An exemplary such re-encoding is provided in Table 4 below.
c. 16-Bit User Defined Instructions (UDIs)
In an embodiment, the smaller bit-width re-encoded ISA allows user-defined instructions (UDIs). UDIs allow designers to add their own instructions. Table 5 provides an exemplary format for the UDIs. In one embodiment, there are 16 UDI instructions available for designer use.
d. Unification of ASEs
In some cases, ISAs are expanded or provided additional features through extensions such as application specific extensions (ASEs). Because such extensions provide new instructions, they generally require use of at least one additional decoder to process the extension instructions. However, the additional decoders generally require additional chip area. Re-encoding one ISA to another according to embodiments of the present invention allow for integration of instructions of the various extensions when the ISA is recoded. As a result, only a single decoder is required for the integrated new ISA.
For example, in one embodiment Legacy MIPS32 ASE instructions (e.g., MIPS32, MIPS-3D ASE, MIPS DSP ASE, MIPS MT ASE, SmartMIPS ASE, not including MIPS16e) are unified to map to a 16-bit ISA combined with a 32-bit ISA. A benefit of the unified ISA is that it does not require a specialized decoder.
Tables 6-9 provide exemplary re-encoding formats for instructions from 4 exemplary ASEs according to an embodiment.
e. New ISA Instructions
As described above, several new instructions are provided in the new ISA according to an embodiment. The new instructions and their formats for one embodiment are summarized in Table 10.
Pseudocode describing the above operation is provided as follows:
In an embodiment, processor operation is unpredictable if the BEQZC instruction is placed in a delay slot of a branch or jump. In an embodiment, the BEQZC instruction has no restrictions or exceptions. In an embodiment, BEQZC does not have a delay slot.
Pseudocode describing the above operation is provided as follows:
In an embodiment, processor operation is unpredictable if the BNEZC instruction is placed in a delay slot of a branch or jump. The BNEZC instruction has no restrictions or exceptions. In an embodiment, the BNEZC does not have a delay slot.
In an embodiment, the JALX instruction is a PC-region branch, not a PC-relative branch. That is, the effective target address is the “current” 256 MB-aligned region determined as follows. In step 332, the lower 28 bits of the effective target address are obtained by shifting the target field left by 2 bits. In an embodiment, this shift is accomplished by concatenating 2 zeros to the target field value. The remaining upper bits of the effective target address are the corresponding bits of the address of the second instruction following the branch (not of the branch itself). In step 336, jumping to the effective target address is performed along with toggling the ISA Mode bit. The operation ends in step 338.
In an embodiment, the JALX instruction has no restrictions and no exceptions. In an embodiment, the effective target address is formed by adding a signed relative offset to the value of the PC. However, forming the jump target address by concatenating the PC and the shifted 26-bit target field rather than adding a signed offset is advantageous if all program code addresses will fit into a 256 MB region aligned on a 256 MB boundary. Using the concatenated PC and 26-bit target address allows a jump to anywhere in the region from anywhere in the region, which a signed relative offset would not allow.
Pseudocode describing the above operation is provided as follows:
In an embodiment, the JALX instruction is a PC-region branch, not a PC-relative branch. That is, the effective target address is the “current” 256 MB-aligned region determined as follows. In step 346, the effective target address is determined by shifting the instr_index field left by 2 bits. In an embodiment, this shift is accomplished by concatenating 2 zeros to the target field value. The remaining upper bits of the effective target address are the corresponding bits of the address of the second instruction following the branch (not of the branch itself). In step 350, the instruction in the delay slot is executed. In step 352, jumping to the effective target address is performed along with toggling the ISA Mode bit. The operation ends in step 354.
In an embodiment, the second embodiment of the JALX instruction has no restrictions and no exceptions. In an embodiment, the effective target address is formed by adding a signed relative offset to the value of the PC. However, forming the jump target address by concatenating the PC and the shifted 26-bit target field rather than adding a signed offset is advantageous if all program code addresses will fit into a 256 MB region aligned on a 256 MB boundary. Using the concatenated PC and 26-bit target address allows a jump to anywhere in the region from anywhere in the region, which a signed relative offset would not allow.
In an embodiment, the second embodiment of the JALX instruction supports only 32-bit aligned branch target addresses. In an embodiment, processor operation is unpredictable if a branch, jump, ERET, DERET, or WAIT instruction is placed in the delay slot of a branch or jump. In an embodiment, the JALX 32-bit instruction has no exceptions.
Pseudocode describing the above operation is provided as follows:
In an embodiment, bit 0 of the target address is always zero (0). Because of this, no address exceptions occur when bit 0 of the source register is one (1). In an embodiment, the effective target address in GPR rs must be 32-bit aligned. If bit 0 of GPR rs is zero and bit 1 of GPR rs is one, then an Address Error exception occurs when the jump target is subsequently fetched as an instruction. The JRC instruction has no exceptions.
Pseudocode describing the above operation is provided as follows:
In an embodiment, the effective address must be 32-bit aligned. If either of the 2 least-significant bits of the address is non-zero, an Address Error exception occurs. In an embodiment, the behavior of the instructions is architecturally undefined if rt equals GPR 31. The behavior of the LRP instruction is also architecturally undefined, if base and rt are the same. This allows the LRP operation to be restarted if an interrupt or exception aborts the operation in the middle of execution. In an embodiment, the behavior of this instruction is also architecturally undefined, if it is placed in a delay slot of a jump or branch. In an embodiment, the LRP exceptions are: TLB Refill, TLB Invalid, Bus Error, Address Error, and Watch.
Pseudocode describing the above operation is provided as follows:
In an embodiment, the LRP instruction may execute for a variable number of cycles and may perform a variable number of stores to memory. Further, in an embodiment. a full restart of the sequence of operations will be performed on return from any exception taken during execution.
In an embodiment, the effective address must be 32-bit aligned. If either of the 2 least-significant bits of the address is non-zero, an address error exception occurs. The behavior of the LWM instruction is architecturally undefined if base is included in reglist. The behavior of the LWM instruction is also architecturally undefined, if base is included in reglist, this allowing an operation to be restarted if an interrupt or exception has aborted the operation in the middle of execution. The behavior of this instruction is also architecturally undefined, if it is placed in a delay slot of a jump or branch.
Pseudocode describing the above operation is provided as follows:
In an embodiment, LWM exceptions are TLB Refill, TLB Invalid, Bus Error, Address Error, and Watch. In an embodiment, the LWM instruction executes for a variable number of cycles and performs a variable number of stores to memory. In an embodiment, a full restart of the sequence of operations is performed on return from any exception taken during execution.
A restriction in an embodiment is that the effective address must be 32-bit aligned. If either of the 2 least-significant bits of the address are non-zero, an Address Error exception occurs. In an embodiment, the behavior of this instruction is architecturally undefined, if it is placed in a delay slot of a jump or branch.
In an embodiment, the SRP instruction may execute for a variable number of cycles and may perform a variable number of stores to memory. Further, in an embodiment, a full restart of the sequence of operations is performed on return from any exception taken during execution. In an embodiment, exceptions to the SRP instruction are TLB Refill, TLB Invalid, TLB Modified, Address Error, Watch.
Pseudocode describing the above operation is provided as follows:
In an embodiment, the restrictions on the SWM instruction are that the effective address must be 32-bit aligned. If either of the 2 least-significant bits of the address is non-zero, an address error exception occurs. In an embodiment, the behavior of this instruction is architecturally undefined, if it is placed in a delay slot of a jump or branch. In an embodiment, the LWM instruction executes for a variable number of cycles and performs a variable number of stores to memory. A full restart of the sequence of operations will be performed on return from any exception taken during execution. In an embodiment, exceptions to SWM are TLB Refill, TLB Invalid, TLB Modified, Address Error, Watch.
Pseudocode describing the above operation is provided as follows:
As shown in
Execution unit 402 preferably implements a load-store (RISC) architecture with single-cycle arithmetic logic unit operations (e.g., logical, shift, add, subtract, etc.). Execution unit 402 interfaces with fetch unit 404, floating point unit 406, load/store unit 408, multiple-divide unit 420, co-processor 422, general purpose registers 424, and core extend unit 434.
Fetch unit 404 is responsible for providing instructions to execution unit 402. In one embodiment, fetch unit 404 includes control logic for instruction cache 412, a recoder for recoding compressed format instructions, dynamic branch prediction and an instruction buffer to decouple operation of fetch unit 404 from execution unit 402. Fetch unit 404 interfaces with execution unit 402, memory management unit 410, instruction cache 412, and bus interface unit 416.
Floating point unit 406 interfaces with execution unit 402 and operates on non-integer data. Floating point unit 406 includes floating point registers 418. In one embodiment, floating point registers 418 may be external to floating point unit 406. Floating point registers 418 may be 32-bit or 64-bit registers used for floating point operations performed by floating point unit 406. Typical floating point operations are arithmetic, such as addition and multiplication, and may also include exponential or trigonometric calculations.
Load/store unit 408 is responsible for data loads and stores, and includes data cache control logic. Load/store unit 408 interfaces with data cache 414 and scratch pad 430 and/or a fill buffer (not shown). Load/store unit 408 also interfaces with memory management unit 410 and bus interface unit 416.
Memory management unit 410 translates virtual addresses to physical addresses for memory access. In one embodiment, memory management unit 410 includes a translation lookaside buffer (TLB) and may include a separate instruction TLB and a separate data TLB. Memory management unit 410 interfaces with fetch unit 404 and load/store unit 408.
Instruction cache 412 is an on-chip memory array organized as a multi-way set associative or direct associative cache such as, for example, a 2-way set associative cache, a 4-way set associative cache, an 8-way set associative cache, et cetera. Instruction cache 412 is preferably virtually indexed and physically tagged, thereby allowing virtual-to-physical address translations to occur in parallel with cache accesses. In one embodiment, the tags include a valid bit and optional parity bits in addition to physical address bits. Instruction cache 412 interfaces with fetch unit 404.
Data cache 414 is also an on-chip memory array. Data cache 414 is preferably virtually indexed and physically tagged. In one embodiment, the tags include a valid bit and optional parity bits in addition to physical address bits. Data cache 414 interfaces with load/store unit 408.
Bus interface unit 416 controls external interface signals for processor core 400. In an embodiment, bus interface unit 416 includes a collapsing write buffer used to merge write-through transactions and gather writes from uncached stores.
Multiply/divide unit 420 performs multiply and divide operations for processor core 400. In one embodiment, multiply/divide unit 420 preferably includes a pipelined multiplier, accumulation registers (accumulators) 426, and multiply and divide state machines, as well as all the control logic required to perform, for example, multiply, multiply-add, and divide functions. As shown in
Co-processor 422 performs various overhead functions for processor core 400. In one embodiment, co-processor 422 is responsible for virtual-to-physical address translations, implementing cache protocols, exception handling, operating mode selection, and enabling/disabling interrupt functions. Co-processor 422 interfaces with execution unit 402. Co-processor 422 includes state registers 428 and general memory 438. State registers 428 are generally used to hold variables used by co-processor 422. State registers 428 may also include registers for holding state information generally for processor core 400. For example, state registers 428 may include a status register. General memory 438 may be used to hold temporary values such as coefficients generated during computations. In one embodiment, general memory 438 is in the form of a register file.
General purpose registers 424 are typically 32-bit or 64-bit registers used for scalar integer operations and address calculations. In one embodiment, general purpose registers 424 are a part of execution unit 424. Optionally, one or more additional register file sets, such as shadow register file sets, can be included to minimize content switching overhead, for example, during interrupt and/or exception processing.
Scratch pad 430 is a memory that stores or supplies data to load/store unit 408. The one or more specific address regions of a scratch pad may be pre-configured or configured programmatically while processor 400 is running. An address region is a continuous range of addresses that may be specified, for example, by a base address and a region size. When base address and region size are used, the base address specifies the start of the address region and the region size, for example, is added to the base address to specify the end of the address region. Typically, once an address region is specified for a scratch pad, all data corresponding to the specified address region are retrieved from the scratch pad.
User Defined Instruction (UDI) unit 434 allows processor core 400 to be tailored for specific applications. UDI 434 allows a user to define and add their own instructions that may operate on data stored, for example, in general purpose registers 424. UDI 434 allows users to add new capabilities while maintaining compatibility with industry standard architectures. UDI 434 includes UDI memory 436 that may be used to store user added instructions and variables generated during computation. In one embodiment, UDI memory 436 is in the form of a register file.
The summary and abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventors, and thus, are not intended to limit the present invention and the claims in any way.
The embodiments herein have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed.
The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others may, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.
The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the claims and their equivalents.
This patent application claims the benefit of U.S. Provisional Patent Application No. 61/051,642 filed on May 8, 2008, entitled “Compact Instruction Set Architecture,” which is incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61051642 | May 2008 | US |
