US20050289325A1 - Instruction set extension using operand bearing NOP instructions - Google Patents
Instruction set extension using operand bearing NOP instructions Download PDFInfo
- Publication number
- US20050289325A1 US20050289325A1 US11/215,862 US21586205A US2005289325A1 US 20050289325 A1 US20050289325 A1 US 20050289325A1 US 21586205 A US21586205 A US 21586205A US 2005289325 A1 US2005289325 A1 US 2005289325A1
- Authority
- US
- United States
- Prior art keywords
- instruction
- operand
- operands
- nop
- opcode
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/3017—Runtime instruction translation, e.g. macros
- G06F9/30174—Runtime instruction translation, e.g. macros for non-native instruction set, e.g. Javabyte, legacy code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30181—Instruction operation extension or modification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30181—Instruction operation extension or modification
- G06F9/30185—Instruction operation extension or modification according to one or more bits in the instruction, e.g. prefix, sub-opcode
Definitions
- the present disclosure pertains to the field of processors. More particularly, the present disclosure pertains to a new instruction or a change to an instruction or an instruction set of a processor.
- an instruction set may have a set of mnemonics that translate into specific opcodes.
- the opcodes are binary values that are understood by the processor and which cause the processor to execute the intended instruction.
- Opcodes are typically a particular length (i.e., a particular number of bits). Therefore, there are a finite number of instructions (i.e., 2 N instructions for an N bit opcode) that may be represented by an opcode, depending on the number of bits dedicated to the opcode.
- One opcode may be designated as a prefix (rather than a particular instruction).
- the prefix indicates that a subsequent value or subsequent values should be decoded differently. In other words, the prefix changes the meaning of at least one subsequent instruction opcode.
- prefixes may be used to define new instructions. In other cases, prefixes may be used to modify the behavior of existing instructions. For example, a prefix may temporarily override default address and/or operand sizes.
- a prefix may be used to specify whether the opcode length is one or two bytes by use of the opcode expansion prefix. Therefore, by the use of prefixes, the total number of potential instructions can be increased. In some cases, a prefix may be used in conjunction with an escape code to define other instructions. In another case, a suffix may be used to specify additional instructions.
- An additional limitation of an instruction set is that there may be a limited number of ways to specify operands. As such, there may a limitation on the number of operands that can be explicitly specified for an instruction.
- One way around this limitation is to implicitly specify where an instruction can find an additional operand by defining a location in the instruction definition, which is understood by the programmers using the instructions.
- the MASKMOVQ instruction included in Intel's Pentium® Processor with MMXTM technology and subsequent Pentium® processors implicitly defines one of its operands to be located in a specified register. In this type of arrangement, a burden is placed on a programmer to move the appropriate operand into the specified location prior to execution of the instruction that uses that operand.
- Another way to implicitly specify operands used in some instruction sets is to group registers together into pairs or quads. For instructions that operate on data which is a multiple of the register size, a single register may be specified and additional adjacent registers may be used to provide the additional operands. This technique has limited flexibility as well because all of the operands are accessed from the specific pre-defined locations in the register pair or quad.
- FIG. 1 a illustrates the use of two source operands from a No Operation (NOP) instruction by another instruction according to one embodiment.
- NOP No Operation
- FIG. 1 b illustrates the use of two operands from a NOP opcode in a different embodiment.
- FIG. 1 c illustrates the use of operands from a NOP opcode by two other opcodes according to one embodiment.
- FIG. 2 a illustrates modules for translating and executing a NOP instruction bearing operands and an another instruction for which the NOP carries the operands.
- FIG. 2 b illustrates a process of providing operands for one instruction with another instruction according to one embodiment.
- FIG. 3 a illustrates one embodiment using a modifier to modify an instruction to use operands from a NOP instruction.
- FIG. 3 b illustrates one embodiment using a modifier to modify a NOP instruction to indicate how its operands should be used.
- FIG. 4 illustrates one embodiment of a system that processes NOP instructions bearing operands.
- FIG. 5 illustrates one embodiment of an instruction performing operations on operands from two instructions.
- FIG. 6 illustrates a process flow for a compiler processing source code to generate a native instruction stream including a NOP instruction bearing operands according to one embodiment.
- a NOP with operands is designed to carry operand information to other instructions preceding and/or following it. Those other instructions may not have enough bits to encode more than a given number of operands (e.g., two source and one destination operand may be specified in some instruction sets). Therefore, if an instruction needs to carry a larger number of operands than is available by the common instruction format, it can be paired with one or more special NOPs, and will use their operand fields as its own.
- Extending an Instruction Set Architecture (ISA) by preserving the semantics of existing operations may be quite desirable as discussed in the background section. Accepting data from more storage locations than typically supported by an ISA may be a very useful way to increase data level parallelism available to programs, to increase the ratio of data handled per instruction, and in some cases to simplify or shorten programs.
- FIG. 1 a illustrates the use of two source operands from a No Operation (NOP) opcode by another instruction according to one embodiment.
- a first opcode 100 has three associated operands, a destination operand (DST) and two source operands (SRC 1 , SRC 2 ).
- An associated operand of an instruction may be specified in a variety of ways.
- An immediate operand may be directly provided in a code sequence adjacent to the opcode or the other operands of the instruction.
- operands may refer to particular memory or register locations. Typically, some encoding is used to reference either a memory location or a register from one or more sets of registers.
- operand specifier This encoding may be referred to as an operand specifier because it specifies where an operand for an instruction can be found.
- an operand may be found directly in line in the code sequence with the instruction and its other operands, or may be in a location specified by one or more operand specifiers.
- an “operand” or “operands” are frequently referred to rather than separately referring to operands, operand specifiers, and the like, and this single nomenclature is used for simplicity and clarity.
- “operand” includes any technique for directly providing an value to be operated on or with or directly or indirectly specifying a location in which a value to be operated on or with may be found.
- an “instruction” is a generic term referring to a variety of representations of an operation or set of operations to be performed.
- An instruction may be represented by a mnemonic, for example, or by an opcode.
- An opcode is typically a sequence of ones and zeroes that may be represented in hexadecimal or in binary or any other convenient format and is interpretable by a processor as indicating the particular operation(s) to be performed.
- the operation(s) to be performed are generally specified in an instruction definition for each instruction. For example, a programmer's reference manual, user's manual, or the like may specify operations performed by a processor in response to a particular instruction.
- a No Operation (NOP) instruction 110 is shown adjacent to the first opcode 100 .
- the NOP instruction 110 has operands.
- the NOP instruction 110 has a destination (DST) operand and two source (SRC 1 , SRC 2 ) operands.
- DST destination
- SRC 1 , SRC 2 source
- the NOP instruction 110 does not cause any operations to occur that would alter architecturally visible variables, but rather is a vessel that bears additional operands for the opcode 100 in this embodiment.
- the NOP is eliminated and its operands used.
- the combination of the opcode 100 and its operands as well as the NOP 110 and its operands are decoded into a second opcode 120 having one destination operand 122 , and four source operands 124 , 126 , 128 , and 130 .
- the first two source operands 124 and 126 are the two source operands from the opcode 100 and the second two operands 128 and 130 are the two source operands from the NOP 110 .
- the opcode 120 reflects, at least partially, the operations(s) indicated by opcode 100 .
- the NOP instruction 110 is eliminated and its operands provided for use by the opcode 120 .
- an opcode is said to “use” or to “operate on” an operand when that operand is specified as one of the arguments to the instruction.
- the “operand” may be in the form of an operand value or an operand specifier that identifies an operand value by location. If an instruction under its architectural definition does or can utilize the value of the operand either in computing a value, accessing a value, or storing a value, then the instruction is said to “use” or “operate on” the operand. Sometimes the operand may not itself or may not change the ultimate result of the instruction, even if it is used.
- FIG. 1 b illustrates the use of two operands from a NOP opcode 150 by another opcode 140 in a different embodiment.
- the instruction set of which opcode 140 is a part may be limited to two unique operands, with one of the operands being both a source and a destination.
- opcode 140 has a first operand that is a destination and source (DST/SRC 1 ) and a second source (SRC 2 ) operand.
- the NOP opcode 150 has a destination and source operand and a second source operand.
- the combination of the opcode 140 and its operands as well as the NOP 150 and its operands are decoded into a second opcode 155 having one destination operand (DST), and four source operands (SRC 1 , SRC 2 , SRC 3 , SRC 4 ), with the first two operands being the two source operands from the opcode 140 and the third and fourth source operands originating as the first and second source operands of the NOP 110 .
- DST destination operand
- SRC 1 , SRC 2 , SRC 3 , SRC 4 source operands
- FIG. 1 c illustrates one embodiment in which operands from a NOP 165 are used by two other opcodes.
- a first opcode 160 having a destination operand and two source operands is transformed into a second opcode 175 which bears two destination operands (DST 1 , DST 2 ) and two source operands (SRC 1 , SRC 2 ).
- the two source operands were originally specified with the opcode 160 , as well as the first destination operand.
- the second destination operand is provided from the NOP 165 .
- a second opcode 170 also having two source operands and one destination operand is transformed into another opcode 180 .
- the opcode 180 has one destination operand from the opcode 170 , as well as a first two source operands from the opcode 170 and third and fourth operands from the NOP 165 .
- one NOP can carry operands for multiple instructions. Further variations may include providing operands to three or more instructions and/or routing different types of instructions to different positions in their new opcodes' operand sets.
- an operand that may be in the position of a particular type of operand (e.g., a destination) of the NOP may be used for a different purpose in conjunction with the opcode that uses it (e.g., the destination operand of the NOP may be used as a source operand for another opcode).
- multiple NOPs may provide operands to a single instruction in some embodiments.
- FIG. 2 a illustrates modules for decoding and executing a NOP bearing operands and the associated instruction for which the NOP carries the operands.
- FIG. 2 b illustrates one embodiment of a process that may be carried out by the apparatus of FIG. 2 a.
- a first instruction 140 (Operand B) and an operand specifying NOP instruction 150 are received by a decode module 205 .
- the opcode 140 and its DST/SRC 1 and SRC 2 operands are processed by a decode module 205 with the NOP 150 and its DST/SRC 1 and SRC 2 operands.
- the decode module 205 may be a variety of different types of decoding, translating or transforming entities, depending on the instruction set(s) involved.
- Some instruction sets include variable length instructions. Often such instruction sets are considered “complex” and the computers designed around such complex instruction sets are referred to as Complex Instruction Set Computer (CISC) architecture computers. On the other hand, there are also Reduced Instruction Set Computer (RISC) architecture machines. Such machines generally use simpler and smaller instruction sets to accomplish the same tasks by using larger numbers of such instructions (i.e., software becomes more complex).
- CISC Complex Instruction Set Computer
- RISC Reduced Instruction Set Computer
- inventive features of the present disclosure may be usefully embodied in a number of alternative processor architectures that will benefit from the techniques disclosed.
- RISC, CISC, and hybrid computer architectures may advantageously utilize the disclosed techniques.
- different kinds of processors in different applications may advantageously choose to extend their instruction set or to include in an initial instruction set the ability to utilize operands specified for one instruction with another instruction.
- General or special purpose processors for computers, servers, personal digital assistants, phones, networking devices, routing devices, etc. may utilize such techniques.
- Processors may be all hardware, may be software emulated or may utilize a combination of hardware and software emulation to support an “instruction set”.
- a processor may have multiple instruction sets.
- Processors may have a single macro-instruction set that is available to a programmer. However, some processors may support multiple macro-instruction sets.
- processors may contain micro-instruction sets or secondary instructions sets.
- a micro-instruction set may be an instruction set into which a processor translates macro-instructions, with the micro-instructions being only used internally by the processor and not typically accessible to programmers or compilers which are limited to using the macro-instruction set.
- a secondary instruction set may be just a different instruction set (not necessarily internal to any component) into which the first instruction set is translated.
- a CISC program may be translated into corresponding instructions from another instructions set which are then executed by either hardware or some hardware and/or software and/or firmware combination.
- a CISC program may be translated into RISC instructions for execution on RISC hardware or into instructions for a Very Long Instruction Word (VLIW) instruction set for execution on a VLIW hardware processor.
- VLIW Very Long Instruction Word
- the decode module 205 of the embodiment of FIG. 2 a decodes the opcode 140 from a first instruction set (e.g., a Complex Instruction Set Computer (CISC) instruction set, a macro-instruction set, etc.) to a second instruction set.
- the second instruction set may be a micro-instruction set for use within a processing device, a RISC instruction set, a VLIW instruction set, or any other appropriate type of an instruction set.
- the decode module 205 may just perform operand re-arrangement to move the operands of the NOP instruction into a position for use by other instructions.
- the decode module 205 may be a hardware decoder in some embodiments.
- a hardware or logic decoder may be useful in converting macroinstructions to microinstructions for execution by a core of a processor.
- the decode module 205 may also be a software module that performs binary translation from one instruction set to another instruction set.
- the decode module may be a combination of hardware and software as desired to convert from one instruction set to another.
- the second instruction set will typically have the capability to allow more operands to be carried by some instructions than the first instruction set. Accordingly, the extra operands added to a NOP instruction in the first instruction set, after the decoding, may be carried along by the instructions with which they are associated.
- the decode module 205 associates NOP operands with the first instruction 140 .
- the first opcode 140 (Opcode A) may be represented by a different opcode, Opcode B.
- Opcode B may have a higher operand carrying capacity than Opcode A since it is a translation of Opcode A into a different instruction set.
- Opcode B is shown as generically having M destination operands, and N source operands, where N and M can be any positive integer numbers.
- Opcode B specifies the same or a similar operation as did Opcode A. The operation may be modified somewhat or dramatically in different embodiments, in order to utilize the added operands.
- Opcode B may be one of a sequence of opcodes that implement Opcode A.
- the new Opcode B is executed by an execution module 215 to perform an operation indicated by Opcode A on some or all of the operands from Opcode A and some or all of the operands from the NOP 150 .
- the execution module 215 may be implemented in a variety of manners.
- the execution module 215 may be a hardware execution unit or set of execution units.
- the execution module 215 may be a combination of hardware and software, or a combination of hardware, firmware, and/or software, etc.
- the NOP instruction itself may specify how its own “extra” operands may be used.
- a NOP may specify a fixed relationship to an opcode that will use the NOP operands.
- Table 1 provides a set of N NOP opcodes that may be used to distribute the N NOP operands to adjacent instructions in different manners. Some subset or superset of these encodings may be used, or different encodings may be used as well, as will be appreciated by one of skill in the art.
- FIG. 3 a illustrates an embodiment in which a modifier 305 is used to modify an opcode 100 to use operands from a NOP 110 .
- the modifier 305 immediately precedes the opcode 100 in the stream of instructions as stored in sequentially fetched memory addresses.
- other modifiers such as prefixes, escape codes, or the like may separate the modifier 305 from the opcode 100 .
- the modifier indicates to the decode module that the opcode will use operands from the NOP 110 .
- one embodiment generates a new opcode 120 having one destination operand 122 from the opcode 100 as well as two source operands 124 and 126 from the opcode 100 , and two source operands 128 and 130 from the NOP 110 .
- FIG. 3 b illustrates another embodiment using a modifier 310 .
- the modifier 310 in FIG. 3 b modifies the NOP 110 instead of modifying the opcode 100 .
- the modifier 310 indicates how the operands of the NOP 110 are to be distributed to other surrounding opcodes.
- one embodiment generates a new opcode 120 having one destination operand 122 from the opcode 100 as well as two source operands 124 and 126 from the opcode 100 , and two source operands 128 and 130 from the NOP 110 .
- the modifiers may be prefixes which are used to specify the distribution or just to indicate the use of the operands from a nearby NOP operand.
- the opcode-modifying prefixes may specify that operands be taken from a fixed location (e.g., a NOP before or after the modified opcode).
- the NOP-modifying prefixes may also specify that the NOP operands be passed to a specifically sequenced (before or after) instruction.
- a variety of prefixes may be used to provide flexibility.
- Table 2 illustrates a more elaborate encoding technique to allow more flexibility as to where additional operands may be obtained.
- Table 2 is provided for prefixes, this technique is equally applicable to NOPs. In other words, a larger number of NOPs could be used than illustrated in Table 1 to provide all the flexibility shown with respect to prefixes in Table 2.
- Prefixes to Specify Operand Usage Before After Operand 1 . . . Operand N Prefix 1 x SRC SRC SRC . x SRC SRC DST . .
- Prefix Q x SRC DST DST . DST SRC SRC . .
- Prefix Q indicates that the NOP operands should be used for the instruction before the NOP, that the first NOP operand should be used as a source operand and that the last NOP operand should be used as a destination operand, and that at least one other destination operand is to be obtained from the NOP.
- Prefixes 2 N+2 +1 through M are particularly flexible in that they allow some operands to be used with a prior instruction and some to be used with a subsequent instruction. Any subset or superset of these encodings may be used to specify how NOP operands may be distributed, as will be appreciated by one of skill in the art.
- other modifiers may be used as appropriate with a particular instruction set. For example, escape codes or suffixes or other instruction modifying values that suggest a different interpretation of a given opcode may be used.
- FIG. 4 illustrates one particular embodiment of a system that processes NOP instructions bearing operands.
- the embodiment of FIG. 4 includes a processor 405 that decomposes macroinstructions into microinstructions.
- the processor 405 is coupled via a processor bus 410 to a memory controller hub 440 .
- the memory controller hub 440 is coupled by a memory bus 420 to a memory 430 and is coupled by a graphics bus 415 to a graphics/video module 412 .
- the processor 405 includes a fetch module 407 , a decode module 409 and an execute module 411 .
- the processor 405 executes instructions from the memory 430 .
- the fetch module 407 fetches macroinstructions from the memory 430 .
- the decode module 409 receives macroinstructions and decodes them into microinstructions for execution by the execute module 411 .
- FIG. 4 illustrates a variety of NOP and instruction combinations that share operands.
- a code segment 432 in the memory 430 includes two opcodes separated in a sequence by a NOP.
- the decode module 409 recognizes that the NOP carries operands for both the preceding and subsequent instructions. These instructions are preceding and subsequent in terms of program execution order and may or may not be in contiguous memory locations depending on their size, any intervening operand specifiers and/or modifiers, as well as depending on the actual order of program execution.
- a code segment 434 illustrates a NOP/opcode pair with the NOP preceding the opcode.
- the NOP may be of the type that carries operands for a single instruction in a fixed location, or may be a NOP that a modifier specifies carries operands for the opcode.
- a code segment 436 illustrates that the NOP may follow the instruction for which it carries operands.
- the NOP itself is typically received by the decode module 409 and essentially discarded after its operands are extracted. Since the NOP itself changes no register or memory values, there is no need to pass the NOP or a translated version thereof beyond the decoder.
- NOP non-limiting integer-programmable gate array
- a NOP is just an example of an instruction that can carry operands that may be convenient because a NOP is generally defined to not change architectural state variables as it executes (although instruction pointers and the like may change).
- Other new instructions could be defined specifically for the purpose of carrying operands.
- some existing opcodes that do not use the entire number of operands that an instruction could be modified by modifiers to use their unused operand slots to carry operands for other instructions.
- NOPs are used in one embodiment, other instructions may be used to carry operands. These other instructions may or may not be executed. However, the operand carrying instruction does not use or operate on the carried operand, but rather passes this operand to the opcode for which it was intended.
- FIG. 5 illustrates one embodiment of an instruction performing operations on operands originally from two instructions.
- an opcode 515 is shown subsequent to decoding by a decode module that expands the instruction set operands from a total of three operands in an external representation to two destination and four source operands.
- the opcode 515 is in an internal format (e.g., a microinstruction format) that supports the larger number of operands shown.
- the opcode 515 has four source operands specifying registers from a register file 510 having N registers.
- a first source operand specifies register 510 -N.
- a second source operand specifies register 510 - 3
- a third source operand specifies register 510 -N- 3
- a fourth source operand specifies register 510 -N- 4 .
- the ability to uniquely specify more operands as shown in FIG. 5 may simplify coding in that it may eliminate the need to shuffle register contents (e.g., via a separate shuffle instruction) since a larger number of individual registers can be addressed by a single opcode.
- two destination specifiers are used to designate where to store results of an arithmetic operation performed by an Arithmetic and Logic Unit (ALU) 520 .
- ALU Arithmetic and Logic Unit
- two results are generated and are stored as specified by a first destination operand in register 510 -N- 1 and 510 -N- 4 .
- two registers may be used to effectively specify one wider register to store results.
- More or fewer source and destination operands may be used in other cases. Thus, great flexibility may be gained by having a generic mechanism to increase the number of operands that may be used by a single instruction.
- butterfly type calculations generating two results may be implemented without implicit specification of operands in an instruction set having too few operand slots to carry the necessary operands with one instruction.
- Another example is a single instruction multiple data (SIMD) type instruction, which may output a larger result than one register can accommodate.
- SIMD single instruction multiple data
- Another example is a complex addressing scheme, in which multiple components are used to calculate an address (e.g., a base, offset, and scale, or other address components may be used in an address calculation).
- more or longer immediate operands may be provided. Any of these operands or operand-like quantities may be specified via a NOP bearing operands.
- FIG. 6 illustrates a process flow for a compiler processing source code to generate a native instruction stream including a NOP instruction bearing operands.
- a source code instruction 600 may specify two destinations and four source operands. The exact number of source and/or destination operands is not particularly important. The compiler, however, determines whether this number is a number that is greater than typically handled by a first or a standard encoding of the source code instruction as indicated in block 610 . If the number of operands specified is the normal number for this type of source code instruction, then the source code instruction is encoded with an opcode that carries all the operands for that opcode as indicated in block 615 .
- the compiler adds a modifier and/or selects an appropriate NOP to designate the extra operands as indicated in block 620 . Then, as indicated in block 630 , the compiler specifies the extra operands with the NOP instruction. Accordingly, source code may be compiled to allow the specification of a larger number of operands than a single opcode can itself carry. Additionally, this technique may be convenient in other scenarios where opcode carrying is not a strict limitation, but it is otherwise convenient to have one instruction bear operands for another instruction.
- a hardware design may go through various stages, from creation to simulation to fabrication.
- Data representing a design may represent the design in a number of manners.
- the hardware may be represented using a hardware description language or another functional description language.
- a circuit level model with logic and/or transistor gates may be produced at some stages of the design process.
- most designs, at some stage reach a level of data representing the physical placement of various devices in the hardware model.
- the data representing the hardware model may be the data specifying the presence or absence of various features on different mask layers for masks used to produce the integrated circuit.
- the data may be stored in any form of a machine readable medium.
- the design typically remains on a machine readable medium.
- An optical or electrical wave modulated or otherwise generated to transmit such information, a memory, or a magnetic or optical storage such as a disc may be the machine readable medium. Any of these mediums may “carry” the design information.
Abstract
Instruction set extension using operand bearing no-operation (NOP) or other instructions. In one embodiment, an apparatus can execute a first instruction with an operand associated with a second instruction. The apparatus includes a decoder to identify an operand associated with the second instruction as being designated for the first instruction. An execution unit executes an operation indicated by the first instruction to operate on the operand associated with the second instruction. The second instruction may occur before or after the first instruction in the program sequence.
Description
- 1. Field
- The present disclosure pertains to the field of processors. More particularly, the present disclosure pertains to a new instruction or a change to an instruction or an instruction set of a processor.
- 2. Description of Related Art
- Computer architects often grapple with the difficulty of extending the instruction set of a processor. Often, instruction sets far outlive their originally contemplated lifespan because an installed base of software makes it profitable to maintain backward compatibility. Therefore, computer architects often add new instructions or new functionality to old instruction sets in order to provide new features yet maintain compatibility with the previously installed software base.
- Adding new functionality to an existing instruction set can be a challenging exercise. Typically, an instruction set may have a set of mnemonics that translate into specific opcodes. The opcodes are binary values that are understood by the processor and which cause the processor to execute the intended instruction. Opcodes, however, are typically a particular length (i.e., a particular number of bits). Therefore, there are a finite number of instructions (i.e., 2N instructions for an N bit opcode) that may be represented by an opcode, depending on the number of bits dedicated to the opcode.
- One common way to overcome this limitation is to use a “prefix”. One opcode may be designated as a prefix (rather than a particular instruction). The prefix indicates that a subsequent value or subsequent values should be decoded differently. In other words, the prefix changes the meaning of at least one subsequent instruction opcode. In some cases, prefixes may be used to define new instructions. In other cases, prefixes may be used to modify the behavior of existing instructions. For example, a prefix may temporarily override default address and/or operand sizes.
- In the ×86 instruction set, a prefix may be used to specify whether the opcode length is one or two bytes by use of the opcode expansion prefix. Therefore, by the use of prefixes, the total number of potential instructions can be increased. In some cases, a prefix may be used in conjunction with an escape code to define other instructions. In another case, a suffix may be used to specify additional instructions.
- An additional limitation of an instruction set is that there may be a limited number of ways to specify operands. As such, there may a limitation on the number of operands that can be explicitly specified for an instruction. One way around this limitation is to implicitly specify where an instruction can find an additional operand by defining a location in the instruction definition, which is understood by the programmers using the instructions. For example, the MASKMOVQ instruction included in Intel's Pentium® Processor with MMX™ technology and subsequent Pentium® processors implicitly defines one of its operands to be located in a specified register. In this type of arrangement, a burden is placed on a programmer to move the appropriate operand into the specified location prior to execution of the instruction that uses that operand.
- Another way to implicitly specify operands used in some instruction sets is to group registers together into pairs or quads. For instructions that operate on data which is a multiple of the register size, a single register may be specified and additional adjacent registers may be used to provide the additional operands. This technique has limited flexibility as well because all of the operands are accessed from the specific pre-defined locations in the register pair or quad.
- Additional creative ways to provide additional functionality and/or flexibility to an instruction set would be beneficial.
- The present invention is illustrated by way of example and not limitation in the Figures of the accompanying drawings.
-
FIG. 1 a illustrates the use of two source operands from a No Operation (NOP) instruction by another instruction according to one embodiment. -
FIG. 1 b illustrates the use of two operands from a NOP opcode in a different embodiment. -
FIG. 1 c illustrates the use of operands from a NOP opcode by two other opcodes according to one embodiment. -
FIG. 2 a illustrates modules for translating and executing a NOP instruction bearing operands and an another instruction for which the NOP carries the operands. -
FIG. 2 b illustrates a process of providing operands for one instruction with another instruction according to one embodiment. -
FIG. 3 a illustrates one embodiment using a modifier to modify an instruction to use operands from a NOP instruction. -
FIG. 3 b illustrates one embodiment using a modifier to modify a NOP instruction to indicate how its operands should be used. -
FIG. 4 illustrates one embodiment of a system that processes NOP instructions bearing operands. -
FIG. 5 illustrates one embodiment of an instruction performing operations on operands from two instructions. -
FIG. 6 illustrates a process flow for a compiler processing source code to generate a native instruction stream including a NOP instruction bearing operands according to one embodiment. - The following description provides instruction set extension using operand bearing instructions. In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures and gate level circuits have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate logic circuits without undue experimentation. While one embodiment is directed to a microprocessor, the techniques described may more generally be applied to other types of electronic processing components that have instruction sets.
- A NOP with operands is designed to carry operand information to other instructions preceding and/or following it. Those other instructions may not have enough bits to encode more than a given number of operands (e.g., two source and one destination operand may be specified in some instruction sets). Therefore, if an instruction needs to carry a larger number of operands than is available by the common instruction format, it can be paired with one or more special NOPs, and will use their operand fields as its own. Extending an Instruction Set Architecture (ISA) by preserving the semantics of existing operations may be quite desirable as discussed in the background section. Accepting data from more storage locations than typically supported by an ISA may be a very useful way to increase data level parallelism available to programs, to increase the ratio of data handled per instruction, and in some cases to simplify or shorten programs.
-
FIG. 1 a illustrates the use of two source operands from a No Operation (NOP) opcode by another instruction according to one embodiment. In the embodiment ofFIG. 1 a, afirst opcode 100 has three associated operands, a destination operand (DST) and two source operands (SRC1, SRC2). An associated operand of an instruction may be specified in a variety of ways. An immediate operand may be directly provided in a code sequence adjacent to the opcode or the other operands of the instruction. Additionally, operands may refer to particular memory or register locations. Typically, some encoding is used to reference either a memory location or a register from one or more sets of registers. This encoding may be referred to as an operand specifier because it specifies where an operand for an instruction can be found. Thus, an operand may be found directly in line in the code sequence with the instruction and its other operands, or may be in a location specified by one or more operand specifiers. Throughout this disclosure, an “operand” or “operands” are frequently referred to rather than separately referring to operands, operand specifiers, and the like, and this single nomenclature is used for simplicity and clarity. Thus, “operand” includes any technique for directly providing an value to be operated on or with or directly or indirectly specifying a location in which a value to be operated on or with may be found. - As used in this disclosure, an “instruction” is a generic term referring to a variety of representations of an operation or set of operations to be performed. An instruction may be represented by a mnemonic, for example, or by an opcode. An opcode is typically a sequence of ones and zeroes that may be represented in hexadecimal or in binary or any other convenient format and is interpretable by a processor as indicating the particular operation(s) to be performed. The operation(s) to be performed are generally specified in an instruction definition for each instruction. For example, a programmer's reference manual, user's manual, or the like may specify operations performed by a processor in response to a particular instruction.
- In the embodiment of
FIG. 1 a, a No Operation (NOP)instruction 110 is shown adjacent to thefirst opcode 100. Unlike most conventional NOP instructions, theNOP instruction 110 has operands. As shown, theNOP instruction 110 has a destination (DST) operand and two source (SRC1, SRC2) operands. TheNOP instruction 110 does not cause any operations to occur that would alter architecturally visible variables, but rather is a vessel that bears additional operands for theopcode 100 in this embodiment. Thus, as shown inFIG. 1 a, the NOP is eliminated and its operands used. In particular, the combination of theopcode 100 and its operands as well as theNOP 110 and its operands are decoded into asecond opcode 120 having onedestination operand 122, and foursource operands source operands opcode 100 and the second twooperands NOP 110. Theopcode 120 reflects, at least partially, the operations(s) indicated byopcode 100. Thus, theNOP instruction 110 is eliminated and its operands provided for use by theopcode 120. - An opcode is said to “use” or to “operate on” an operand when that operand is specified as one of the arguments to the instruction. As previously noted, the “operand” may be in the form of an operand value or an operand specifier that identifies an operand value by location. If an instruction under its architectural definition does or can utilize the value of the operand either in computing a value, accessing a value, or storing a value, then the instruction is said to “use” or “operate on” the operand. Sometimes the operand may not itself or may not change the ultimate result of the instruction, even if it is used.
-
FIG. 1 b illustrates the use of two operands from aNOP opcode 150 by anotheropcode 140 in a different embodiment. In the embodiment ofFIG. 1 b, the instruction set of which opcode 140 is a part may be limited to two unique operands, with one of the operands being both a source and a destination. Thus,opcode 140 has a first operand that is a destination and source (DST/SRC1) and a second source (SRC2) operand. Similarly, theNOP opcode 150 has a destination and source operand and a second source operand. In this embodiment, the combination of theopcode 140 and its operands as well as theNOP 150 and its operands are decoded into asecond opcode 155 having one destination operand (DST), and four source operands (SRC1, SRC2, SRC3, SRC4), with the first two operands being the two source operands from theopcode 140 and the third and fourth source operands originating as the first and second source operands of theNOP 110. -
FIG. 1 c illustrates one embodiment in which operands from aNOP 165 are used by two other opcodes. In the embodiment ofFIG. 1 c, afirst opcode 160 having a destination operand and two source operands is transformed into asecond opcode 175 which bears two destination operands (DST1, DST2) and two source operands (SRC1, SRC2). The two source operands were originally specified with theopcode 160, as well as the first destination operand. However, the second destination operand is provided from theNOP 165. - A
second opcode 170 also having two source operands and one destination operand is transformed into anotheropcode 180. Theopcode 180 has one destination operand from theopcode 170, as well as a first two source operands from theopcode 170 and third and fourth operands from theNOP 165. Thus, one NOP can carry operands for multiple instructions. Further variations may include providing operands to three or more instructions and/or routing different types of instructions to different positions in their new opcodes' operand sets. Furthermore, an operand that may be in the position of a particular type of operand (e.g., a destination) of the NOP may be used for a different purpose in conjunction with the opcode that uses it (e.g., the destination operand of the NOP may be used as a source operand for another opcode). Furthermore, multiple NOPs may provide operands to a single instruction in some embodiments. -
FIG. 2 a illustrates modules for decoding and executing a NOP bearing operands and the associated instruction for which the NOP carries the operands.FIG. 2 b illustrates one embodiment of a process that may be carried out by the apparatus ofFIG. 2 a. As indicated inblock 225 ofFIG. 2 b, a first instruction 140 (Operand B) and an operand specifyingNOP instruction 150 are received by adecode module 205. As illustrated inFIG. 2 a, theopcode 140 and its DST/SRC1 and SRC2 operands are processed by adecode module 205 with theNOP 150 and its DST/SRC1 and SRC2 operands. Thedecode module 205 may be a variety of different types of decoding, translating or transforming entities, depending on the instruction set(s) involved. - Some instruction sets include variable length instructions. Often such instruction sets are considered “complex” and the computers designed around such complex instruction sets are referred to as Complex Instruction Set Computer (CISC) architecture computers. On the other hand, there are also Reduced Instruction Set Computer (RISC) architecture machines. Such machines generally use simpler and smaller instruction sets to accomplish the same tasks by using larger numbers of such instructions (i.e., software becomes more complex).
- It is expressly understood that the inventive features of the present disclosure may be usefully embodied in a number of alternative processor architectures that will benefit from the techniques disclosed. RISC, CISC, and hybrid computer architectures may advantageously utilize the disclosed techniques. Moreover, different kinds of processors in different applications may advantageously choose to extend their instruction set or to include in an initial instruction set the ability to utilize operands specified for one instruction with another instruction. General or special purpose processors for computers, servers, personal digital assistants, phones, networking devices, routing devices, etc., may utilize such techniques. Processors may be all hardware, may be software emulated or may utilize a combination of hardware and software emulation to support an “instruction set”.
- Moreover, a processor may have multiple instruction sets. Processors may have a single macro-instruction set that is available to a programmer. However, some processors may support multiple macro-instruction sets. Furthermore, processors may contain micro-instruction sets or secondary instructions sets. A micro-instruction set may be an instruction set into which a processor translates macro-instructions, with the micro-instructions being only used internally by the processor and not typically accessible to programmers or compilers which are limited to using the macro-instruction set. Similarly, a secondary instruction set may be just a different instruction set (not necessarily internal to any component) into which the first instruction set is translated. For example, a CISC program may be translated into corresponding instructions from another instructions set which are then executed by either hardware or some hardware and/or software and/or firmware combination. For example, a CISC program may be translated into RISC instructions for execution on RISC hardware or into instructions for a Very Long Instruction Word (VLIW) instruction set for execution on a VLIW hardware processor. In any case, all of these different instruction sets and/or processors are just different embodiments that can benefit from the disclosed techniques.
- The
decode module 205 of the embodiment ofFIG. 2 a decodes theopcode 140 from a first instruction set (e.g., a Complex Instruction Set Computer (CISC) instruction set, a macro-instruction set, etc.) to a second instruction set. The second instruction set may be a micro-instruction set for use within a processing device, a RISC instruction set, a VLIW instruction set, or any other appropriate type of an instruction set. In other embodiments, thedecode module 205 may just perform operand re-arrangement to move the operands of the NOP instruction into a position for use by other instructions. - The
decode module 205 may be a hardware decoder in some embodiments. For example, a hardware or logic decoder may be useful in converting macroinstructions to microinstructions for execution by a core of a processor. Thedecode module 205 may also be a software module that performs binary translation from one instruction set to another instruction set. Moreover, the decode module may be a combination of hardware and software as desired to convert from one instruction set to another. The second instruction set will typically have the capability to allow more operands to be carried by some instructions than the first instruction set. Accordingly, the extra operands added to a NOP instruction in the first instruction set, after the decoding, may be carried along by the instructions with which they are associated. - As indicated in
block 235, thedecode module 205 associates NOP operands with thefirst instruction 140. Subsequent to decoding by thedecode module 205, the first opcode 140 (Opcode A) may be represented by a different opcode, Opcode B. As mentioned, Opcode B may have a higher operand carrying capacity than Opcode A since it is a translation of Opcode A into a different instruction set. Opcode B is shown as generically having M destination operands, and N source operands, where N and M can be any positive integer numbers. Opcode B, however, specifies the same or a similar operation as did Opcode A. The operation may be modified somewhat or dramatically in different embodiments, in order to utilize the added operands. Moreover, Opcode B may be one of a sequence of opcodes that implement Opcode A. - As indicated in
block 245, the new Opcode B is executed by anexecution module 215 to perform an operation indicated by Opcode A on some or all of the operands from Opcode A and some or all of the operands from theNOP 150. Much like thedecode module 205, theexecution module 215 may be implemented in a variety of manners. For example, theexecution module 215 may be a hardware execution unit or set of execution units. Alternatively, theexecution module 215 may be a combination of hardware and software, or a combination of hardware, firmware, and/or software, etc. - In some embodiments, the NOP instruction itself may specify how its own “extra” operands may be used. In one embodiment, a NOP may specify a fixed relationship to an opcode that will use the NOP operands. In other embodiments, it may be desirable to provide a set of NOP opcodes that allow flexibility as to how the NOP operands may be used. For example, Table 1 provides a set of N NOP opcodes that may be used to distribute the N NOP operands to adjacent instructions in different manners. Some subset or superset of these encodings may be used, or different encodings may be used as well, as will be appreciated by one of skill in the art.
TABLE 1 NOP Opcodes to Specify Operand Usage Operand 1 . . . Operand N NOP 1 SRC . . . SRC . DST SRC SRC . . NOP N DST . . . DST - In other embodiments, the NOP itself may not specify how its operands are to be used, but rather various modifiers may be inserted into the instruction stream to specify NOP operand usage.
FIG. 3 a illustrates an embodiment in which amodifier 305 is used to modify anopcode 100 to use operands from aNOP 110. In the embodiment ofFIG. 3 a, themodifier 305 immediately precedes theopcode 100 in the stream of instructions as stored in sequentially fetched memory addresses. In other embodiments, other modifiers such as prefixes, escape codes, or the like may separate themodifier 305 from theopcode 100. The modifier indicates to the decode module that the opcode will use operands from theNOP 110. As previously shown, one embodiment generates anew opcode 120 having onedestination operand 122 from theopcode 100 as well as twosource operands opcode 100, and twosource operands NOP 110. -
FIG. 3 b illustrates another embodiment using amodifier 310. Themodifier 310 inFIG. 3 b modifies theNOP 110 instead of modifying theopcode 100. Themodifier 310 indicates how the operands of theNOP 110 are to be distributed to other surrounding opcodes. As previously shown, one embodiment generates anew opcode 120 having onedestination operand 122 from theopcode 100 as well as twosource operands opcode 100, and twosource operands NOP 110. - In one embodiment, the modifiers (either 305 or 310) may be prefixes which are used to specify the distribution or just to indicate the use of the operands from a nearby NOP operand. In some embodiments, the opcode-modifying prefixes may specify that operands be taken from a fixed location (e.g., a NOP before or after the modified opcode). Similarly, the NOP-modifying prefixes may also specify that the NOP operands be passed to a specifically sequenced (before or after) instruction. Alternatively, a variety of prefixes may be used to provide flexibility.
- Table 2 illustrates a more elaborate encoding technique to allow more flexibility as to where additional operands may be obtained. Although Table 2 is provided for prefixes, this technique is equally applicable to NOPs. In other words, a larger number of NOPs could be used than illustrated in Table 1 to provide all the flexibility shown with respect to prefixes in Table 2.
TABLE 2 Prefixes to Specify Operand Usage Before After Operand 1. . . Operand N Prefix 1 x SRC SRC SRC . x SRC SRC DST . . Prefix Q x SRC DST DST . DST SRC SRC . . Prefix 2N+2 x DST DST DST Prefix 2N+2 + 1 x x SRC-BEF DST-AFT . SRC-BEF SRC-AFT DST-AFT . . Prefix M x x DST-BEF . . . SRC-AFT - As an example, according to Table 2, Prefix Q indicates that the NOP operands should be used for the instruction before the NOP, that the first NOP operand should be used as a source operand and that the last NOP operand should be used as a destination operand, and that at least one other destination operand is to be obtained from the NOP.
Prefixes 2N+2+1 through M are particularly flexible in that they allow some operands to be used with a prior instruction and some to be used with a subsequent instruction. Any subset or superset of these encodings may be used to specify how NOP operands may be distributed, as will be appreciated by one of skill in the art. Moreover, other modifiers may be used as appropriate with a particular instruction set. For example, escape codes or suffixes or other instruction modifying values that suggest a different interpretation of a given opcode may be used. -
FIG. 4 illustrates one particular embodiment of a system that processes NOP instructions bearing operands. The embodiment ofFIG. 4 includes aprocessor 405 that decomposes macroinstructions into microinstructions. Theprocessor 405 is coupled via aprocessor bus 410 to amemory controller hub 440. Thememory controller hub 440 is coupled by amemory bus 420 to amemory 430 and is coupled by agraphics bus 415 to a graphics/video module 412. Theprocessor 405 includes a fetchmodule 407, adecode module 409 and an executemodule 411. Theprocessor 405 executes instructions from thememory 430. The fetchmodule 407 fetches macroinstructions from thememory 430. Thedecode module 409 receives macroinstructions and decodes them into microinstructions for execution by the executemodule 411. -
FIG. 4 illustrates a variety of NOP and instruction combinations that share operands. Acode segment 432 in thememory 430 includes two opcodes separated in a sequence by a NOP. In this case, thedecode module 409 recognizes that the NOP carries operands for both the preceding and subsequent instructions. These instructions are preceding and subsequent in terms of program execution order and may or may not be in contiguous memory locations depending on their size, any intervening operand specifiers and/or modifiers, as well as depending on the actual order of program execution. - A
code segment 434 illustrates a NOP/opcode pair with the NOP preceding the opcode. In thiscode segment 434, the NOP may be of the type that carries operands for a single instruction in a fixed location, or may be a NOP that a modifier specifies carries operands for the opcode. Similarly, acode segment 436 illustrates that the NOP may follow the instruction for which it carries operands. The NOP itself is typically received by thedecode module 409 and essentially discarded after its operands are extracted. Since the NOP itself changes no register or memory values, there is no need to pass the NOP or a translated version thereof beyond the decoder. - In some embodiments, other instructions other than NOP instructions may be used to carry operands for other instructions. A NOP is just an example of an instruction that can carry operands that may be convenient because a NOP is generally defined to not change architectural state variables as it executes (although instruction pointers and the like may change). Other new instructions could be defined specifically for the purpose of carrying operands. Alternatively, some existing opcodes that do not use the entire number of operands that an instruction could be modified by modifiers to use their unused operand slots to carry operands for other instructions. Thus, while NOPs are used in one embodiment, other instructions may be used to carry operands. These other instructions may or may not be executed. However, the operand carrying instruction does not use or operate on the carried operand, but rather passes this operand to the opcode for which it was intended.
- The ability to specify additional operands may be quite advantageous in some embodiments, as new functions may be provided and/or instruction sequences may be simplified and/or shortened.
FIG. 5 illustrates one embodiment of an instruction performing operations on operands originally from two instructions. In the embodiment ofFIG. 5 , anopcode 515 is shown subsequent to decoding by a decode module that expands the instruction set operands from a total of three operands in an external representation to two destination and four source operands. As a result, theopcode 515 is in an internal format (e.g., a microinstruction format) that supports the larger number of operands shown. - In this embodiment, the
opcode 515 has four source operands specifying registers from aregister file 510 having N registers. A first source operand specifies register 510-N. A second source operand specifies register 510-3, whereas a third source operand specifies register 510-N-3, and a fourth source operand specifies register 510-N-4. The ability to uniquely specify more operands as shown inFIG. 5 may simplify coding in that it may eliminate the need to shuffle register contents (e.g., via a separate shuffle instruction) since a larger number of individual registers can be addressed by a single opcode. - In the embodiment of
FIG. 5 , two destination specifiers are used to designate where to store results of an arithmetic operation performed by an Arithmetic and Logic Unit (ALU) 520. In this example, two results are generated and are stored as specified by a first destination operand in register 510-N-1 and 510-N-4. In other words, two registers may be used to effectively specify one wider register to store results. More or fewer source and destination operands may be used in other cases. Thus, great flexibility may be gained by having a generic mechanism to increase the number of operands that may be used by a single instruction. - For example, butterfly type calculations generating two results may be implemented without implicit specification of operands in an instruction set having too few operand slots to carry the necessary operands with one instruction. Another example is a single instruction multiple data (SIMD) type instruction, which may output a larger result than one register can accommodate. Another example is a complex addressing scheme, in which multiple components are used to calculate an address (e.g., a base, offset, and scale, or other address components may be used in an address calculation). Yet another example is that more or longer immediate operands may be provided. Any of these operands or operand-like quantities may be specified via a NOP bearing operands.
-
FIG. 6 illustrates a process flow for a compiler processing source code to generate a native instruction stream including a NOP instruction bearing operands. As indicated inFIG. 6 , asource code instruction 600 may specify two destinations and four source operands. The exact number of source and/or destination operands is not particularly important. The compiler, however, determines whether this number is a number that is greater than typically handled by a first or a standard encoding of the source code instruction as indicated inblock 610. If the number of operands specified is the normal number for this type of source code instruction, then the source code instruction is encoded with an opcode that carries all the operands for that opcode as indicated inblock 615. - If a greater number operands are specified in the source code than typically handled by a selected opcode, then the compiler adds a modifier and/or selects an appropriate NOP to designate the extra operands as indicated in
block 620. Then, as indicated inblock 630, the compiler specifies the extra operands with the NOP instruction. Accordingly, source code may be compiled to allow the specification of a larger number of operands than a single opcode can itself carry. Additionally, this technique may be convenient in other scenarios where opcode carrying is not a strict limitation, but it is otherwise convenient to have one instruction bear operands for another instruction. - A hardware design may go through various stages, from creation to simulation to fabrication. Data representing a design may represent the design in a number of manners. First, as is useful in simulations, the hardware may be represented using a hardware description language or another functional description language. Additionally, a circuit level model with logic and/or transistor gates may be produced at some stages of the design process. Furthermore, most designs, at some stage, reach a level of data representing the physical placement of various devices in the hardware model. In the case where conventional semiconductor fabrication techniques are used, the data representing the hardware model may be the data specifying the presence or absence of various features on different mask layers for masks used to produce the integrated circuit. In any representation of the design, the data may be stored in any form of a machine readable medium. In a software design, the design typically remains on a machine readable medium. An optical or electrical wave modulated or otherwise generated to transmit such information, a memory, or a magnetic or optical storage such as a disc may be the machine readable medium. Any of these mediums may “carry” the design information.
- Thus, instruction set extension using operand bearing instructions is disclosed. While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art upon studying this disclosure.
Claims (16)
1-32. (canceled)
33. A compiler comprising:
a code segment to identify a first instruction in response to a first source code instruction as having a number greater than a predetermined number of operands for a first translation of said first source code instruction;
a code segment to specify a second instruction to have an operand for said first instruction in response to said first source code instruction and said number greater than the predetermined number of operands.
34. The compiler of claim 33 wherein said code segment to specify said second instruction is to specify a No Operation instruction having a plurality of operand specifiers specified with said first source code instruction.
35. The compiler of claim 34 further comprising a code segment to add a modifier to indicate that said second instruction is to specify operands for said first instruction.
36. The compiler of claim 35 wherein said modifier modifies said first instruction.
37. The compiler of claim 35 wherein said modifier modifies said second instruction.
38. The compiler of claim 36 wherein said modifier is a prefix.
39. The compiler of claim 34 wherein said No Operation instruction is one of a plurality of operand-specifying No Operation instructions.
40. A method comprising:
receiving a first instruction with a first operand;
receiving a second instruction;
associating said first operand with said second instruction.
41. The method of claim 40 further comprising:
discarding said first instruction.
42. The method of claim 40 further comprising:
performing an operation specified by said second instruction using said first operand.
43. The method of claim 40 wherein said first operand is a source operand and wherein performing the operation specified by said second instruction using said first operand comprises operating directly on said first operand without altering said first operand due to the first instruction.
44. The method of claim 42 wherein said second instruction is a NOP instruction that does not alter said first operand.
45. The method of claim 41 wherein said first operand is a destination operand and wherein performing comprises generating a first result for storage in a first destination specified by the second instruction and a second results for storage in a location specified by said first operand specifier.
46. The method of claim 40 wherein said first instruction specifies a first operand specifier for use with said second instruction and a second operand specifier for use with said second instruction.
47-56. (canceled)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/215,862 US20050289325A1 (en) | 2002-06-19 | 2005-08-30 | Instruction set extension using operand bearing NOP instructions |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/176,020 US6957321B2 (en) | 2002-06-19 | 2002-06-19 | Instruction set extension using operand bearing NOP instructions |
US11/215,862 US20050289325A1 (en) | 2002-06-19 | 2005-08-30 | Instruction set extension using operand bearing NOP instructions |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/176,020 Division US6957321B2 (en) | 2002-06-19 | 2002-06-19 | Instruction set extension using operand bearing NOP instructions |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050289325A1 true US20050289325A1 (en) | 2005-12-29 |
Family
ID=29734035
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/176,020 Expired - Lifetime US6957321B2 (en) | 2002-06-19 | 2002-06-19 | Instruction set extension using operand bearing NOP instructions |
US11/215,862 Abandoned US20050289325A1 (en) | 2002-06-19 | 2005-08-30 | Instruction set extension using operand bearing NOP instructions |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/176,020 Expired - Lifetime US6957321B2 (en) | 2002-06-19 | 2002-06-19 | Instruction set extension using operand bearing NOP instructions |
Country Status (1)
Country | Link |
---|---|
US (2) | US6957321B2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080126756A1 (en) * | 2006-06-20 | 2008-05-29 | Nec Electronics Corporation | Data processing apparatus and data processing method |
US11042637B1 (en) * | 2018-02-01 | 2021-06-22 | EMC IP Holding Company LLC | Measuring code sharing of software modules based on fingerprinting of assembly code |
Families Citing this family (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1340142A2 (en) * | 2000-11-27 | 2003-09-03 | Koninklijke Philips Electronics N.V. | Data processing apparatus with many-operand instruction |
US6957321B2 (en) * | 2002-06-19 | 2005-10-18 | Intel Corporation | Instruction set extension using operand bearing NOP instructions |
US7444471B1 (en) * | 2002-12-30 | 2008-10-28 | Transmeta Corporation | Method and system for using external storage to amortize CPU cycle utilization |
US7577824B2 (en) * | 2003-09-08 | 2009-08-18 | Altera Corporation | Methods and apparatus for storing expanded width instructions in a VLIW memory for deferred execution |
US7664933B2 (en) * | 2005-01-17 | 2010-02-16 | Denso Corporation | Microcomputer and encoding system for instruction code and CPU |
US20070061551A1 (en) * | 2005-09-13 | 2007-03-15 | Freescale Semiconductor, Inc. | Computer Processor Architecture Comprising Operand Stack and Addressable Registers |
US7958436B2 (en) * | 2005-12-23 | 2011-06-07 | Intel Corporation | Performing a cyclic redundancy checksum operation responsive to a user-level instruction |
US7925957B2 (en) * | 2006-03-20 | 2011-04-12 | Intel Corporation | Validating data using processor instructions |
JP2008027341A (en) * | 2006-07-25 | 2008-02-07 | Matsushita Electric Ind Co Ltd | Instruction set and information processor |
US8370606B2 (en) * | 2007-03-16 | 2013-02-05 | Atmel Corporation | Switching data pointers based on context |
US7797516B2 (en) * | 2007-03-16 | 2010-09-14 | Atmel Corporation | Microcontroller with low-cost digital signal processing extensions |
US20090113403A1 (en) * | 2007-09-27 | 2009-04-30 | Microsoft Corporation | Replacing no operations with auxiliary code |
US8281109B2 (en) * | 2007-12-27 | 2012-10-02 | Intel Corporation | Compressed instruction format |
US8078836B2 (en) | 2007-12-30 | 2011-12-13 | Intel Corporation | Vector shuffle instructions operating on multiple lanes each having a plurality of data elements using a common set of per-lane control bits |
JP5193624B2 (en) * | 2008-02-19 | 2013-05-08 | ルネサスエレクトロニクス株式会社 | Data processor |
GB2486739B (en) * | 2010-12-24 | 2018-09-19 | Qualcomm Technologies Int Ltd | Instruction execution |
JP5367020B2 (en) * | 2011-06-24 | 2013-12-11 | 株式会社ソニー・コンピュータエンタテインメント | Information processing apparatus, information processing method, program, and information storage medium |
US9329869B2 (en) | 2011-10-03 | 2016-05-03 | International Business Machines Corporation | Prefix computer instruction for compatibily extending instruction functionality |
US9354874B2 (en) | 2011-10-03 | 2016-05-31 | International Business Machines Corporation | Scalable decode-time instruction sequence optimization of dependent instructions |
US9286072B2 (en) | 2011-10-03 | 2016-03-15 | International Business Machines Corporation | Using register last use infomation to perform decode-time computer instruction optimization |
US9513912B2 (en) * | 2012-07-27 | 2016-12-06 | Micron Technology, Inc. | Memory controllers |
US10250464B2 (en) * | 2014-10-15 | 2019-04-02 | Accedian Networks Inc. | Area efficient traffic generator |
US10761852B2 (en) * | 2015-09-30 | 2020-09-01 | International Business Machines Corporation | Extending data range addressing |
US10877759B2 (en) | 2015-09-30 | 2020-12-29 | International Business Machines Corporation | Managing the capture of information in applications with prefix instructions |
US10394568B2 (en) | 2015-09-30 | 2019-08-27 | International Business Machines Corporation | Exception handling for applications with prefix instructions |
US9870305B2 (en) | 2015-09-30 | 2018-01-16 | International Business Machines Corporation | Debugging of prefixed code |
US10620957B2 (en) * | 2015-10-22 | 2020-04-14 | Texas Instruments Incorporated | Method for forming constant extensions in the same execute packet in a VLIW processor |
US10331449B2 (en) * | 2016-01-22 | 2019-06-25 | Arm Limited | Encoding instructions identifying first and second architectural register numbers |
US9977677B2 (en) | 2016-04-07 | 2018-05-22 | International Business Machines Corporation | Execution slice with supplemental instruction port for an instruction using a source operand from another instruction port |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5212777A (en) * | 1989-11-17 | 1993-05-18 | Texas Instruments Incorporated | Multi-processor reconfigurable in single instruction multiple data (SIMD) and multiple instruction multiple data (MIMD) modes and method of operation |
US5239654A (en) * | 1989-11-17 | 1993-08-24 | Texas Instruments Incorporated | Dual mode SIMD/MIMD processor providing reuse of MIMD instruction memories as data memories when operating in SIMD mode |
US5903772A (en) * | 1993-10-29 | 1999-05-11 | Advanced Micro Devices, Inc. | Plural operand buses of intermediate widths coupling to narrower width integer and wider width floating point superscalar processing core |
US5905893A (en) * | 1996-06-10 | 1999-05-18 | Lsi Logic Corporation | Microprocessor adapted for executing both a non-compressed fixed length instruction set and a compressed variable length instruction set |
US20030023960A1 (en) * | 2001-07-25 | 2003-01-30 | Shoab Khan | Microprocessor instruction format using combination opcodes and destination prefixes |
US6779101B1 (en) * | 2000-03-07 | 2004-08-17 | University Of Washington | Method and apparatus for processing compressed VLIW subinstruction opcodes |
US6957321B2 (en) * | 2002-06-19 | 2005-10-18 | Intel Corporation | Instruction set extension using operand bearing NOP instructions |
US7191317B1 (en) * | 1999-07-21 | 2007-03-13 | Broadcom Corporation | System and method for selectively controlling operations in lanes |
US7234042B1 (en) * | 1999-07-14 | 2007-06-19 | Broadcom Corporation | Identification bit at a predetermined instruction location that indicates whether the instruction is one or two independent operations and indicates the nature the operations executing in two processing channels |
US7257806B1 (en) * | 1999-10-21 | 2007-08-14 | Hewlett-Packard Development Company, L.P. | System and method for efficiently passing information between compiler and post-compile-time software |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US516666A (en) * | 1894-03-20 | Electric-railway system | ||
US3657705A (en) | 1969-11-12 | 1972-04-18 | Honeywell Inc | Instruction translation control with extended address prefix decoding |
DE69032812T2 (en) * | 1989-07-07 | 1999-04-29 | Hitachi Ltd | Device and method for parallel processing |
US5438668A (en) | 1992-03-31 | 1995-08-01 | Seiko Epson Corporation | System and method for extraction, alignment and decoding of CISC instructions into a nano-instruction bucket for execution by a RISC computer |
US5353420A (en) | 1992-08-10 | 1994-10-04 | Intel Corporation | Method and apparatus for decoding conditional jump instructions in a single clock in a computer processor |
US5572206A (en) | 1994-07-06 | 1996-11-05 | Microsoft Corporation | Data compression method and system |
US5768553A (en) | 1995-10-30 | 1998-06-16 | Advanced Micro Devices, Inc. | Microprocessor using an instruction field to define DSP instructions |
AU1406997A (en) | 1995-12-15 | 1997-07-14 | Intel Corporation | Instruction encoding techniques for microcontroller architecture |
US5822559A (en) | 1996-01-02 | 1998-10-13 | Advanced Micro Devices, Inc. | Apparatus and method for aligning variable byte-length instructions to a plurality of issue positions |
TW334546B (en) * | 1996-03-18 | 1998-06-21 | Hitachi Ltd | Data processor |
US5845102A (en) | 1997-03-03 | 1998-12-01 | Advanced Micro Devices, Inc. | Determining microcode entry points and prefix bytes using a parallel logic technique |
US6539470B1 (en) * | 1999-11-16 | 2003-03-25 | Advanced Micro Devices, Inc. | Instruction decode unit producing instruction operand information in the order in which the operands are identified, and systems including same |
-
2002
- 2002-06-19 US US10/176,020 patent/US6957321B2/en not_active Expired - Lifetime
-
2005
- 2005-08-30 US US11/215,862 patent/US20050289325A1/en not_active Abandoned
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5212777A (en) * | 1989-11-17 | 1993-05-18 | Texas Instruments Incorporated | Multi-processor reconfigurable in single instruction multiple data (SIMD) and multiple instruction multiple data (MIMD) modes and method of operation |
US5239654A (en) * | 1989-11-17 | 1993-08-24 | Texas Instruments Incorporated | Dual mode SIMD/MIMD processor providing reuse of MIMD instruction memories as data memories when operating in SIMD mode |
US5903772A (en) * | 1993-10-29 | 1999-05-11 | Advanced Micro Devices, Inc. | Plural operand buses of intermediate widths coupling to narrower width integer and wider width floating point superscalar processing core |
US5905893A (en) * | 1996-06-10 | 1999-05-18 | Lsi Logic Corporation | Microprocessor adapted for executing both a non-compressed fixed length instruction set and a compressed variable length instruction set |
US7234042B1 (en) * | 1999-07-14 | 2007-06-19 | Broadcom Corporation | Identification bit at a predetermined instruction location that indicates whether the instruction is one or two independent operations and indicates the nature the operations executing in two processing channels |
US7191317B1 (en) * | 1999-07-21 | 2007-03-13 | Broadcom Corporation | System and method for selectively controlling operations in lanes |
US7257806B1 (en) * | 1999-10-21 | 2007-08-14 | Hewlett-Packard Development Company, L.P. | System and method for efficiently passing information between compiler and post-compile-time software |
US6779101B1 (en) * | 2000-03-07 | 2004-08-17 | University Of Washington | Method and apparatus for processing compressed VLIW subinstruction opcodes |
US20030023960A1 (en) * | 2001-07-25 | 2003-01-30 | Shoab Khan | Microprocessor instruction format using combination opcodes and destination prefixes |
US6957321B2 (en) * | 2002-06-19 | 2005-10-18 | Intel Corporation | Instruction set extension using operand bearing NOP instructions |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080126756A1 (en) * | 2006-06-20 | 2008-05-29 | Nec Electronics Corporation | Data processing apparatus and data processing method |
US7849295B2 (en) * | 2006-06-20 | 2010-12-07 | Nec Electronics Corporation | Data processing apparatus and data processing method including dividing data to be processed |
US11042637B1 (en) * | 2018-02-01 | 2021-06-22 | EMC IP Holding Company LLC | Measuring code sharing of software modules based on fingerprinting of assembly code |
Also Published As
Publication number | Publication date |
---|---|
US20030236965A1 (en) | 2003-12-25 |
US6957321B2 (en) | 2005-10-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6957321B2 (en) | Instruction set extension using operand bearing NOP instructions | |
KR101703743B1 (en) | Accelerated interlane vector reduction instructions | |
JP5299979B2 (en) | RISC processor and register flag bit processing method | |
WO2001069376A9 (en) | Method and apparatus for processor code optimization using code compression | |
US20090282220A1 (en) | Microprocessor with Compact Instruction Set Architecture | |
JP2005332361A (en) | Program command compressing device and method | |
Reshadi et al. | An efficient retargetable framework for instruction-set simulation | |
TW201333821A (en) | System, apparatus and method for generating a loop alignment count or a loop alignment mask | |
Reshadi et al. | Hybrid-compiled simulation: An efficient technique for instruction-set architecture simulation | |
US8621444B2 (en) | Retargetable instruction set simulators | |
US5774694A (en) | Method and apparatus for emulating status flag | |
CN111930426A (en) | Reconfigurable computing dual-mode instruction set architecture and application method thereof | |
US20230205436A1 (en) | Zero cycle memory initialization | |
EP4202656A1 (en) | Random data usage | |
US20230061618A1 (en) | Bfloat16 square root and/or reciprocal square root instructions | |
EP4141659A1 (en) | Bfloat16 arithmetic instructions | |
EP4202659A1 (en) | Conversion instructions | |
US20230068781A1 (en) | Bfloat16 scale and/or reduce instructions | |
EP4202660A1 (en) | Conversion instructions | |
US20230205527A1 (en) | Conversion instructions | |
EP4300293A1 (en) | Add with rotation instruction and support | |
US20230072105A1 (en) | Bfloat16 comparison instructions | |
US20230067810A1 (en) | Bfloat16 fused multiply instructions | |
EP4202657A1 (en) | Memory controller with arithmetic logic unit and/or floating point unit | |
US10671395B2 (en) | Application specific instruction-set processor (ASIP) for simultaneously executing a plurality of operations using a long instruction word |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SHEAFFER, GAD S.;REEL/FRAME:016947/0061 Effective date: 20020613 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |