Register provides opcode instructions

Abstract

An instruction has an opcode and at least one data operand, the opcode identifying a data processing operation to be performed on the at least one data operand. For a register-provided opcode instruction specifying at least one source register, at least a portion of the opcode is a register-provided opcode represented by a first portion of data stored in the at least one source register for the register-provided opcode instruction, and the at least one data operand includes data represented by a second portion of data stored in the at least one source register. The register-provided opcode is used to select between different data processing operations supported for the same instruction encoding of the register-provided opcode instruction.

Description

Technical Field

[0001] This technology relates to the field of data processing. Background Technology

[0002] A processor can execute instructions according to a specific instruction set architecture (ISA) supported by the processor. An ISA can specify certain features that the processor needs to provide to ensure that program code written according to the ISA runs correctly when executed on the processor. For example, an ISA can specify instruction encoding for a given instruction set, which represents the corresponding data processing operation to be performed. Manufacturers of specific processor implementations that support the ISA can then include appropriate circuit logic set in the hardware to support the data processing operations that need to be performed by instructions defined according to the ISA. Summary of the Invention

[0003] At least some embodiments provide an apparatus comprising: a plurality of registers for storing data; processing circuitry for performing data processing using data obtained from the registers; and an instruction decoder for decoding an instruction specifying an opcode and at least one data operand to control the processing circuitry to perform a data processing operation identified by the opcode on the at least one data operand to generate a result value to be written to a destination register; wherein, for a register providing an opcode instruction specifying at least one source register: at least a portion of the opcode is a register-provided opcode represented by a first portion of data stored in the at least one source register for which the register-provided opcode is provided; the at least one data operand includes data represented by a second portion of data stored in the at least one source register; in response to the register-provided opcode instruction, the instruction decoder is configured to control the processing circuitry to select, at least based on the register-provided opcode, one of a plurality of different data processing operations supported by the same instruction encoding for the register-provided opcode instruction; and the plurality of different data processing operations include at least two different data processing operations that, for at least a subset of possible input values ​​of the at least one data operand, are both capable of generating a result value having a value or data format different from the at least one data operand.

[0004] At least some examples provide a data processing method comprising: decoding an instruction for a specified opcode and at least one data operand to control processing circuitry to perform a data processing operation identified by the opcode on the at least one data operand to generate a result value to be written to a destination register; and when the decoded instruction is a register-provided opcode instruction specifying at least one source register: at least a portion of the opcode is a register-provided opcode represented by a first portion of data stored in the at least one source register of the register-provided opcode; the at least one data operand includes data represented by a second portion of data stored in the at least one source register; in response to the register-provided opcode instruction, the processing circuitry selects one of a plurality of different data processing operations supported by the same instruction encoding for the register-provided opcode instruction, at least based on the register-provided opcode; and the plurality of different data processing operations include at least two different data processing operations that, for at least a subset of possible input values ​​of the at least one data operand, are both capable of generating a result value having a value or data format different from the at least one data operand.

[0005] At least some examples provide a computer program for controlling a host data processing device to simulate the processing of a target program by a target processing circuit. The computer program includes: register emulation program logic for maintaining a register emulation data structure of a plurality of registers of the simulated target processing circuit; and instruction decoding program logic for decoding instructions of the target program that specify an opcode and at least one data operand to control the host data processing device to perform a data processing operation identified by the opcode on the at least one data operand, to generate a result value to be written to a portion of a register emulation data structure corresponding to a destination register among the plurality of registers; wherein an opcode is provided for a register specifying at least one source register: at least a portion of the opcode is derived from at least one instruction that provides the opcode to the register. A register provides an opcode, represented by a first portion of the data corresponding to a source register; at least one data operand includes data represented by a second portion of the data corresponding to at least one source register; in response to a register-provided opcode instruction, instruction decoding program logic is configured to control a host data processing device to select, at least based on the register-provided opcode, one of a plurality of different data processing operations supported by the same instruction encoding for the register-provided opcode instruction; and the plurality of different data processing operations include at least two different data processing operations that, for at least one subset of the possible input values ​​of the at least one data operand, are both capable of generating a result value having a value or data format different from that of the at least one data operand.

[0006] At least some examples provide a computer-readable storage medium for storing the aforementioned computer programs. This storage medium may be a transient or non-transitory storage medium. Attached Figure Description

[0007] Other aspects, features, and advantages of this technology will become apparent from the following description of examples, which are read in conjunction with the accompanying drawings, in which:

[0008] Figure 1 An example of a data processing device is shown schematically;

[0009] Figure 2 Examples of custom instructions supported by the instruction set architecture are shown;

[0010] Figure 3 An alternative example of a data processing device that supports custom instructions is shown;

[0011] Figure 4 The condition status register is shown, which can be used by condition instructions to control conditional operations based on whether the condition flags stored in the condition status register meet the test conditions.

[0012] Figure 5 Different types of instructions are shown, including register-provided opcode instructions;

[0013] Figure 6 This illustrates how condition flags can be passed to an instruction as operands or opcodes when the instruction's register specifier specifies a register identifier corresponding to the program counter register.

[0014] Figure 7 An example is shown in which the instruction encoding indicates whether the instruction is a non-register-provided opcode instruction or a register-provided opcode instruction;

[0015] Figure 8 The illustration shows an example where data in a general-purpose register specified by an instruction whose opcode is provided by a register can be used to provide additional opcode bits to select which transformation function to apply to one or more data operands of the instruction;

[0016] Figure 9 An example is shown where a register provides an opcode instruction, where a condition flag stored in a condition status register is used as part of the opcode;

[0017] Figure 10 An example is shown where a register provides an opcode instruction, where data in the source register is used to select whether to access one or more other source registers from an integer register file or a floating-point register file;

[0018] Figure 11This is a flowchart illustrating the data processing method; and

[0019] Figure 12 An example of a simulator that can be used is shown. Detailed Implementation

[0020] The device has: multiple registers for storing data; processing circuitry for performing data processing using data obtained from the registers; and an instruction decoder for decoding an instruction with a specified opcode and at least one data operand to control the processing circuitry to perform a data processing operation identified by the opcode on at least one data operand to generate a result value to be written to a destination register.

[0021] An instruction's opcode represents a specific data processing operation performed on at least one data operand. For a typical instruction set architecture, the opcode is defined by a subset of bits within the instruction code. The data operand to be operated on can be represented by an immediate value within the instruction code or by data stored in at least one source register. Instruction code space is often very limited when designing instruction set architectures. The number of bits available for direct encoding of the opcode within the instruction code may be limited. While one option for encoding a wider range of data processing operations could be to extend the total length of each instruction to accommodate more opcode bits, this would require wider signal paths to carry the instruction on wired signal paths within the processing hardware and additional memory space for storing program code, which may be undesirable due to increased circuit area and power consumption.

[0022] In the techniques discussed below, a Register Provided Opcode (RPO) instruction is provided that specifies at least one source register. For a Register Provided Opcode instruction, at least a portion of the opcode is represented by a first portion of data stored in at least one source register specified by the RPO instruction. A second portion of the data stored in the at least one source register represents at least one data operand of the RPO instruction. In response to the RPO instruction, the instruction decoder can control the processing circuitry to select one of a plurality of different data processing operations supported by the same instruction encoding for the RPO instruction, based at least on the Register Provided Opcode. These different data processing operations may include at least two different data processing operations that, for a subset of possible input values ​​for the at least one data operand, are both capable of producing a result value having a value or data format different from the at least one data operand.

[0023] It seems counterintuitive that a portion of the register data stored in a register should be used as the opcode to select the type of data processing operation to be performed. One might argue that having to read registers to identify the instruction type delays instruction processing, a stark contrast to the traditional approach of using registers to provide the instruction's data operands and using instruction codes to provide the opcode. However, the inventors recognized that for certain types of instructions, the number of opcode bits in the instruction code may be limited, and the range of different data processing operations that are expected to be supported may be greater than the number of different codes for the opcode bits in that instruction code. By using registers to provide additional opcode bits, the range of different data processing operations that can be supported can be increased, which is beneficial for performance because it allows some operations that would otherwise require multiple instructions to be executed instead of using a single instruction.

[0024] In some examples, at least one source register of the RPO instruction can be specified separately from the destination register, such that the source value of the instruction does not include the previous value stored in the destination register before the result value of the instruction is written to the destination register. In other examples, the previous value in the destination register itself can be used as a source operand of the instruction; therefore, in this case, at least one source register can include the destination register. Thus, in some cases, the RPO instruction can specify only one source register, which can be used as both a source register and a destination register. Other types of instructions can specify a source register that is separate from the destination register, making the instruction a non-destructive instruction that does not overwrite the source operand. Other variations of the instruction can specify multiple source registers, which can include the destination register or exclude the destination register. Therefore, unless otherwise stated, references to source registers in this application can include the destination register.

[0025] The register provides the opcode and at least one data operand, represented by a first portion and a second portion of data stored in at least one source register. In some examples, the second portion of the data may correspond to a set of one or more source registers that are completely separate from the first portion of the data stored in a different set of one or more source registers. In this case, there may be no sharing of data and opcode in the register specified by the RPO instruction as the same as the source register.

[0026] Alternatively, for certain variants of the RPO instruction, the data value stored in a particular source register may have a portion of the data considered as part of the first portion of the data representing the opcode, and a separate portion of the data stored in the same register may be considered as part of the second portion of the data representing at least one data operand. Therefore, depending on the specific implementation chosen, some registers may be partitioned between the opcode representing the portion and the data operand representing the portion. For example, if the number of additional opcode bits required by a particular implementation is less than the number of bits in a register, the remaining bits can be used to represent the data operand. Similarly, if the width of the data operand for a given operation is less than the width of a register, the remaining bits in the register can be used to provide the additional opcode bits.

[0027] As described above, register-provided opcodes are used to select between two or more distinct data processing operations supported by processing circuitry in response to instructions with the same instruction code having an RPO instruction. While some implementations may use a single bit in the register-provided opcode to select between two alternative data processing operations for the same code, this technique is particularly useful if the same instruction code for the RPO instruction supports three or more distinct data processing operations, where the specific operation to be performed is selected based on the register-provided opcode. More specifically, by utilizing a register-provided opcode with N bits, up to a maximum of 2... N Different data processing operations. It should be understood that the instruction decoder and processing circuitry can support multiple different types of RPO instructions with different instruction codes (e.g., the opcode portion identified in the instruction code itself has different values), each of these different types of RPO instructions having a different set of data processing operations that can be selected based on the opcode provided by the instruction's register.

[0028] The different data processing operations supported by a given type of RPO instruction include at least two (and possibly more, as described above) different data processing operations, each capable of producing a result value that is different from or has a different data format than the at least one data operand from which the result was generated. Therefore, the different data processing operations can include not only no-operation functions that keep the result the same, or register move functions that simply move data values ​​from one register to another without changing their value or format. While RPO instructions can also be conditional, such that the execution of a selected data processing operation among two or more different data processing operations depends on a certain conditional state value, which may sometimes result in a result value having the same value as the corresponding data operand, there are still two optional results for the instruction, corresponding to different data processing operations capable of changing the data operand to produce the result, with the opcode provided by the register allowing selection between these two optional results. Therefore, instead of simply using registers to provide opcodes to conditionally select whether to perform a data processing operation, the RPO instruction's registers are actually used to provide opcodes to select between completely different data processing operations applied to at least one data operand to produce a result value, similar to how an instruction decoder would use opcode bits in the instruction encoding to select between different types of data processing operations.

[0029] The different data processing operations supported by a given encoding of an RPO instruction can vary in different ways. In one example, at least two different data processing operations include at least two different transformation functions for generating a result value from at least one data operand. For example, at least two different transformation functions can include different subsets or combinations of one or more of the following:

[0030] At least one arithmetic operator (e.g., addition, subtraction, multiplication, division, multiplication-addition, or square root, or combinations thereof);

[0031] At least one logical operator (e.g., AND, NOT, OR, NOR, XOR, NAND, etc. or combinations thereof).

[0032] At least one shift operator (e.g., arithmetic left shift, arithmetic right shift, logical left shift, or logical right shift), and

[0033] At least one data format conversion operator (e.g., any conversion between different integer, fixed-point, or floating-point formats).

[0034] Therefore, the different options available for the data processing operation to be performed can vary depending on which arithmetic sequences are applied to the at least one data operand to produce a result. The different options available for the data processing operation to be performed, which are different values ​​of opcodes provided to registers, can vary depending on which sequences of arithmetic, logical, shift, or data format conversion operators are applied to the at least one data operand to produce a result.

[0035] Alternatively, or in addition to choosing among optional transformation functions, the register-provided opcode can also be used to select which of at least two register files is used to provide at least one source register for storing at least one data operand of the RPO instruction or a destination register for storing the result value. In such an implementation, one of the source registers can come from a default register file that is used regardless of the value of the register-provided opcode, such that a register in the default register file can be read to first obtain the register-provided opcode, but once the register-provided opcode is read, the value of the data stored in that register can be used to select whether to select one or more other source registers and / or destination registers from the first or second register file. For example, different register files can correspond to registers used to store operands of different types. For example, at least two register files can include two or more of the following: an integer register file for storing integer operands, a floating-point register file for storing floating-point operands, and a vector register file for storing vector operands. Therefore, by using registers to provide opcodes to select which register file to use for the data operand or the destination register, this avoids the need to use bits in the instruction code itself to represent the operation, thus freeing up more code to represent the specific data conversion required.

[0036] Registers may include system registers with certain architecture-defined functions, such as a program counter (indicating the current point of execution in the program being executed), exception handling registers for controlling exception generation and return, and various mode indicator registers or status registers indicating the processor's current mode or operating state. Additionally, registers may include general-purpose registers that do not have any architecture-defined functions but are typically used by instructions to store operands and the results of processing operations to be performed.

[0037] In some examples, the opcode provided by the register can be represented by data stored in at least a portion of a general-purpose register, which is designated as one of the source registers of at least one source register for the RPO instruction. It seems counterintuitive that data in a general-purpose register would be used as the opcode, since general-purpose registers are conventionally used to provide data operands for instructions (e.g., data values ​​to be processed by arithmetic instructions) or operands for generating memory access instruction addresses. However, by using data from a register to provide additional opcode bits, this expands the number of possible data processing operations that can be encoded and represented by a given instruction, thus opening up support for additional operations that would otherwise have to be executed using a sequence of multiple instructions.

[0038] In some examples, the data stored in a general-purpose register can be used partly to represent the register-provided opcode and partly to represent the data operand, thus separating a single register between the two uses.

[0039] In other examples, register-provided opcode instructions can specify two or more source registers (optionally including the destination register for the destructive encoding of the instruction as described above). At least one source register can be used to represent the data operand, but a separate general-purpose register can be used to provide the register-provided opcode, such that the general-purpose register providing the register-provided opcode does not provide any portion of the at least one data operand to the instruction. Therefore, at least one data operand can be independent of the data in the general-purpose register used to provide the register-provided opcode. This method of separating which registers are used to represent the register-provided opcode and which registers are used to provide the data operand makes it easier for the compiler to compile program code using RPO instructions because, when allocating which registers to represent the data operand, the compiler does not need to consider whether a portion of the register must represent the opcode and therefore cannot be used to represent data. For example, the compiler can choose to use a specific general-purpose register from the set of general-purpose registers to provide the opcode for the RPO instruction and select the register from the remaining set of registers to provide the data operand, simplifying the compiler's register allocation decisions.

[0040] One might wonder why, if the bits in the instruction code that identify the general-purpose register providing the opcode can be omitted, these bits cannot be used directly to identify the register-provided opcode. However, the number of general-purpose registers is often relatively limited, meaning that only a certain number (e.g., four or five) of the bits in the instruction code can be used to specify the general-purpose register. Therefore, using data from that general-purpose register to provide the register-provided opcode allows for more opcode bits and thus allows for a wider range of data processing operations that can be represented.

[0041] Another approach could be to provide a condition status register, which is used by at least one variant of the RPO instruction to provide the opcode. The condition status register can store at least one condition indicator, which can be used by condition instructions to control the processing circuitry to determine whether to perform a conditional operation based on whether the at least one condition indicator satisfies a test condition specified by the condition instruction. Therefore, while at least one condition indicator would typically simply control whether a conditional operation is performed, for RPO instructions, the bits associated with the at least one condition indicator can be passed as additional opcode bits to the instruction decoder. This allows for more complex choices between performing different data processing operations (e.g., different processing transformation functions) based on at least one condition indicator for instructions that do not require additional conditional functionality, effectively expanding the width of the RPO instruction's opcode and allowing for the representation of a wider range of operations.

[0042] While using condition status registers may provide fewer additional opcode bits compared to using general-purpose registers to provide register-based opcodes, and therefore may not support a wide range of different data processing operations, one advantage of using at least one condition indicator to provide additional opcode bits is that it is easier for the compiler to utilize. This is because many compilers are written to try to utilize general-purpose registers as extensively as possible to represent data operands. Register pressure means that the number of available general-purpose registers is often less than the number of different variables that might be used in a program, and therefore, once all general-purpose registers have been used, if another variable is needed, data from previously used registers may need to be saved to memory to make room for the new variable. If the previously saved variable is needed again in the future, it needs to be reloaded into a register to replace another variable. Therefore, register data overflowing into memory and filling back into registers increases the consumed memory bandwidth and thus degrades performance. Therefore, to try to maintain the highest possible performance, it is advantageous if the compiler can utilize as many general-purpose registers as possible to store data operands. Therefore, if the condition status indicators in the condition status register are sufficient to encode the number of different data processing operations expected for a given encoding of an RPO instruction, general-purpose registers that can be used for data operands can be reserved, which can improve performance.

[0043] In some variations, all condition indicators in the condition status register can be used to provide a register-provided opcode. Alternatively, only a first subset of the condition indicators can be used to provide a register-provided opcode, while the remaining subset of condition indicators serves as a data operand. Specifically, if the RPO instruction is a conditional RPO instruction, for at least one of two or more distinct data processing operations that can be selected based on a register-provided opcode, the selected data processing operation may depend on whether the remaining subset of the condition indicators satisfies the test conditions specified by the conditional RPO instruction. Therefore, processor designers can again weigh the number of condition indicators required for any conditional operation of a control instruction against which of these indicators can be used instead of representing a portion of the opcode, such that if the number of required test conditions is limited, fewer condition indicators can be used to provide the condition status as a data operand, and more condition indicator bits can be used to represent the register-provided opcode, thereby increasing the number of distinct data processing operations that can be selected in response to a single encoding of the RPO instruction.

[0044] At least one condition indicator stored in the condition status register can represent an attribute of the result of an earlier instruction. For example, certain types of instructions can be designated as condition-setting instructions that control the instruction decoder to control the processing circuitry to perform a given data processing operation, and also set or update at least one condition indicator to a value that depends on an attribute of the result of performing the given data processing operation. For example, the condition status indicator can indicate whether the result of the data processing operation is negative, whether the result is zero, whether the result of a signed operation causes an overflow, and / or whether the result of an unsigned operation generates a carry or overflows. Such condition status indicators are useful for enabling operations to be conditional on comparison functions such as greater than, greater than or equal to, equal to, and not equal to.

[0045] One potential problem arising from using register-provided opcodes is that some instruction set architectures may not provide the ability to designate the condition status register as a direct source register for program instructions. For example, in most instruction set architectures that support conditional instructions, whether the condition status register is read in response to an instruction can be specified by the opcode portion encoded in the instruction code itself, which directly indicates whether the instruction type is a conditional instruction. However, if register-provided opcodes are used to expand the number of available opcode bits, this could diminish some of the advantages of using register-provided opcodes in the first place if some of those opcode bits must be used to indicate whether the condition status register should be accessed.

[0046] To avoid consuming opcode bits when the condition status register provides the opcode, one approach is to utilize the fact that a general-purpose register identifier can be assigned to indicate the program counter register, which stores the program counter indicating the address of the instruction representing the current point of program execution. Sometimes, it may be efficient for an instruction to perform an operation using the program counter; therefore, a specific value of the source register identifier can be assigned as a predetermined program counter register indication value to allow such instructions to use the program counter as a source operand. For a given instruction other than an RPO instruction, when the source register identifier has this predetermined program counter register indication value, at least one data operand of that given instruction may include the program counter stored in the program counter register.

[0047] However, for RPO instructions, when the RPO instruction specifies a predetermined program counter register indicator value for the source register identifier, this can be interpreted as meaning that at least one source register should include a condition status register, and therefore, the value of at least one condition indicator should be passed to the circuit logic that selects the data processing operation to be performed based on the register-provided opcode. This approach means that the condition status indicator can be used to represent a portion of the opcode without assigning additional values ​​to the register identifier, solely to identify that the condition status register should be used as the source register. This can be useful because the encoding number typically used for the register identifier might already be chosen as a power of 2, and therefore providing additional encoding might require additional bits for each register specifier in the instruction encoding, further reducing the number of available opcode bits. The program counter register is unlikely to be used to indicate that the register provides the opcode because it is not possible to set the program counter register to an arbitrary value to select the data processing operation to be performed by a subsequent RPO instruction (since modifying the value of the program counter would result in leaving the branch of that subsequent instruction). Therefore, by reusing the program counter register indicator value instead of indicating that the condition status indicator should be provided as a data operand, this improves the efficiency of the instruction set encoding.

[0048] The above description has illustrated two examples of using general-purpose registers or condition status registers to encode opcodes provided by registers. It should be understood that some implementations of the RPO instruction can combine these methods, such that both the general-purpose register and the condition status register provide the appropriate portion of the instruction's opcode for selecting which data processing operation to perform.

[0049] The RPO instruction can be an instruction that specifies only one source register identifier (which can be separate from the destination register or the same as the destination register mentioned above). However, the RPO instruction approach can be particularly useful for instructions that specify multiple source register identifiers, because as the number of source register identifiers increases, the space used to represent the opcode bits in the instruction code becomes increasingly limited. Therefore, for some variants, it may be necessary to replace a portion of the specified opcode with one of these source registers.

[0050] For RPO instructions, the opcode provided by the register may not be the only part of the opcode. The instruction code for RPO instructions can also specify an immediate value representing another part of the opcode, allowing the selection of the chosen data processing operation based on both the immediate value and the opcode provided by the register.

[0051] Not all instructions supported by the instruction decoder need to be treated as RPO instructions. The instruction decoder may also support at least one non-register provided opcode (non-RPO) instruction, which specifies at least one source register for which the opcode is represented only by a portion of the instruction code of the non-RPO instruction, and the data in at least one source register of the instruction is used only as at least one data operand, and not as part of the opcode.

[0052] For the instruction encoding portion representing the opcode of a non-RPO instruction, RPO and non-RPO instructions may have different encodings. Therefore, it is possible to identify from the instruction encoding itself whether it is necessary to read one of the instruction's source registers to identify other opcode bits. In some examples, for at least some encodings of this portion of the instruction encoding representing the opcode in a non-RPO instruction, specific bits of that portion of the instruction encoding may indicate whether the instruction should be considered a non-RPO instruction or an RPO instruction. Other approaches may have a more arbitrary mapping of the instruction encoding portion corresponding to the opcode of a non-RPO instruction, where a subset of the possible values ​​of that opcode portion is assigned to represent RPO instructions, and the remaining subset of the values ​​of that portion represents the opcode of a non-RPO instruction.

[0053] More specifically, if for each instruction supported by the instruction decoder, a specific portion of the instruction code located in a predetermined part of the instruction code is considered to represent the instruction-coded opcode, then a non-RPO instruction can be an instruction in a first subset of instructions having values ​​for the instruction-coded opcode. For a second subset of instructions having values ​​for the instruction-coded opcode, an immediate value specified in another part of the instruction code, different from the instruction-coded opcode, can specify another part of the opcode. An RPO instruction can be an instruction in a second subset of instructions in which the instruction-coded opcode and immediate value have values. The division between RPO and non-RPO instructions in the second subset of instructions can be arbitrary, depending on the specific processor implementation, where some encodings of the instruction-coded opcode and immediate value represent RPO instructions, while others represent non-RPO instructions, depending on the needs of the specific processor implementation. However, by having a designated predefined part with instruction encoding that distinguishes whether an instruction can only be a non-RPO instruction (as in the case of the first subset of instructions) or whether the instruction can represent an RPO instruction (as in the case of the second subset of instructions), the control of the processor pipeline can be simplified, because for the first subset of instructions, it can be guaranteed that the registers referenced in the instruction will be used as data operands, and therefore there is no need to select the data processing operation to be performed.

[0054] The techniques discussed above are particularly useful for implementing custom instructions defined within a given instruction set architecture, allowing processor designers to implement certain custom data processing operations not specified by the instruction set architecture itself. For example, an ISA designer might define a core instruction set that needs to be implemented by a processor supporting a given ISA. This could include some relatively simple operations (such as arithmetic or logical operations) as well as other more complex operations that are still expected to be used frequently enough to justify specifying a particular non-RPO instruction code for that specific operation. However, it is typically impossible to support every possible processing function that a particular processor designer might want to implement within the architecturally-mandated instruction definition; therefore, in a typical ISA, any additional processing operation may need to be broken down into multiple instructions.

[0055] However, for processors designed for specific applications, there may be certain types of processing operations that are likely to be executed frequently. Therefore, it would be beneficial for processor designers to be able to choose to implement hardware capable of executing this operation in a single instruction, even if not specified by the ISA. Thus, a given ISA can provide coding space for a limited number of custom instructions, which can have codes defined in the given ISA, but for those codes, the corresponding data processing operations are implementation-specific custom data processing operations, not those specified by the given ISA.

[0056] Unlike regular architecture-defined instructions, for custom instructions, the regular instruction encoding opcode may be practically useless for encoding the specific data processing operation performed in response to that custom instruction. This is because it may be necessary to distinguish the fact that the instruction is a custom instruction from all other instructions authorized by a given ISA architecture. Therefore, relatively few additional bits are available in the instruction encoding to select which specific custom data processing operation to perform. For example, while it is possible to specify an immediate value in the instruction, only a relatively small number of bits may be available for this, especially if the custom instruction specifies multiple source registers. Therefore, for custom instructions, it is particularly useful to provide implementations that use register data stored in the specific source registers of the instruction as additional opcode space to expand the total number of data processing operations that can be supported for a given encoding of a particular custom instruction.

[0057] Note that whether a given encoding of a custom instruction is decoded as a register-provided opcode instruction or as a non-RPO instruction may not be specified by a given ISA. The designer of the processor's specific hardware implementation can choose which encodings of a custom instruction to decode using register-provided opcodes, and which to decode using opcodes represented only within the instruction encoding itself. The instruction set architecture itself can simply specify that the custom instruction is an instruction with an instruction-encoded opcode having a value from a subset of values, and can specify the format used to specify register specifiers or immediate values, but then leaves the use of data from the referenced registers and immediate values ​​to the designer of the specific hardware system, arbitrarily choosing the partitioning between the data operand bits and the opcode bits based on how many different data processing operations the hardware implementer wants to support.

[0058] The above-described technology can be implemented in a hardware processor having hardware circuitry features that provide the aforementioned processing circuitry and exception control circuitry. However, in other examples, the technology can be implemented in a program used to control a host data processing device to simulate the processing of a target program by the target processing circuitry. The computer program providing the simulation can be stored on a storage medium. The storage medium can be a transient or non-transient storage medium.

[0059] Such simulated computer programs can be used to allow target programs developed according to a target instruction set architecture to execute on host data processing devices that do not inherently support the target instruction set architecture. This is useful for a variety of reasons, such as allowing legacy code to execute on newer devices that do not support the architecture for which code was developed, or for testing target programs developed for a future instruction set architecture before any hardware device supporting that new instruction set architecture becomes available. The hardware implementation may have hardware circuitry providing the aforementioned features, while the software simulation can provide corresponding software functionality, such as program logic and data structures, that emulates the functionality of the corresponding hardware, allowing the target program to execute on the simulation in a manner similar to how the target program would be executed by the corresponding hardware device.

[0060] Therefore, a computer program can have register emulation program logic and instruction decoding program logic that emulate the functions of the aforementioned registers and instruction decoders. The instruction decoding program logic can support the interpretation of instructions in the target program as register-provided opcode instructions as described above, such that a specific data processing operation to be performed in response to the instruction is selected based on a first portion of data corresponding to at least one source register specified in the register-provided opcode instruction, as simulated by the register emulation program logic using a register emulation data structure. For example, the register emulation data structure can be a data structure stored in the memory of the host data processing device.

[0061] Figure 1 An example of a portion of a data processing device 2 having a processing pipeline for processing instructions is schematically shown. For example, device 2 may be a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit). An instruction decoder 4 receives instructions fetched from an instruction cache or memory and decodes them to generate control signals 6 for controlling other parts of the system to perform corresponding data processing operations. Processing device 2 has registers 8 disposed in hardware for storing data values ​​that can be used to represent data operands of the instructions and / or registers that can represent a portion of the opcode identifying the instructions. Execution unit 10 includes various types of processing circuitry for performing different types of data processing operations represented by the corresponding instructions decoded by instruction decoder 4. For example, execution circuitry 10 may include: an arithmetic / logic unit (ALU) for performing arithmetic or logical operations on integer operands; a floating-point unit for performing floating-point operations involving numbers represented in floating-point notation; and a load / store unit for executing load / store instructions to load data from the memory system (…). Figure 1 Data (not shown) is loaded into register 8 or stored from register 8 into the memory system. Write-back stage 12 writes the result of the executed instruction back to register 8.

[0062] like Figure 2 As shown, instructions processed by the processing device can have an encoding that specifies an opcode (opc) 20 for each instruction, and depending on the specific instruction, may also specify an immediate value #imm 22 and / or one or more register identifiers that identify the destination register Rd and optionally one or more other source registers Rn, Rm. For some instructions, the destination register Rd itself can be used as both a destination register and another source register, such that the previous value stored in that register is used as a source operand, and then the result of the instruction is written back to the destination register that overwrites the source operand. For example... Figure 2 As shown, different types of instructions can specify different numbers of registers, and therefore can have different numbers of bits available to encode any immediate value 22.

[0063] like Figure 1 As shown, register 8 may include various types of registers, including general-purpose registers in integer register file 30 for storing integer values, general-purpose registers in floating-point register file 32 for storing floating-point values, and certain system registers with functions defined for the architecture of the control system operation, such as the program counter (PC) register 34 indicating the current point of instruction execution, and the registers referred to below. Figure 4 The condition status register 36 is described. Figure 2 The destination and source register specifiers shown in the instructions typically select registers from one of the general-purpose register files 30 and 32. In some implementations, the program counter register 34 may be considered one of the general-purpose registers with a specific register number. Which register file 30 or 32 is to be accessed in response to a given instruction can be identified from the instruction-encoded opcode 20, such that an instruction with one value of its instruction-encoded opcode can select a register from the integer register file 30, while another instruction with a different opcode value can select a register from the floating-point register file 32 (even if the register specifier is the same as the register specifier used to select from the integer register file of the first instruction).

[0064] like Figure 2As shown, the possible encodings of the opcode field 20 in the instruction encoding can have one of a range of values, from values ​​where all bits of the opcode are equal to 0 to values ​​where all bits of the opcode field 20 are equal to 1. A first subset of the possible values ​​of the opcode field can represent an architecture-granted instruction 24, for which the encoding format and data processing operations performed are specified by the instruction set architecture supported by the processing device 2. For architecture-granted instructions, the opcode can be represented solely by the opcode field 20 within the instruction encoding, or it can be represented by a combination of the opcode field 20 and the immediate value field 22. The registers specified in the instruction encoding can be used to provide data operands to be processed in the data processing operations represented by the instruction.

[0065] On the other hand, for a second subset of the possible values ​​of opcode field 20, these instructions can represent custom instructions 26. While the ISA defines how the instructions should be encoded, the specific data processing operation represented by the instruction can be implementation-defined. That is, the designer of a particular processing system to be implemented in hardware is free to choose the specific data processing operation represented by the instruction. Therefore, software written for that particular processor implementation can use custom instruction encoding to control specific operations not defined in the instruction set architecture, allowing these instructions to be executed in a single instruction, which would otherwise require a combination of multiple instructions. This allows for more efficient execution of certain common operations required by a particular implementation. For example, if a system uses a specific fixed-point or floating-point number format, certain custom instruction encodings can be assigned to represent conversions between those special number formats, allowing for more efficient conversion operations than using arithmetic, logical, or shift instruction sequences to perform equivalent operations. Another example where custom instructions might be useful is when a register has multiple bits, each corresponding to a given external device, and provides bits indicating a specific state of that device (e.g., whether the device is enabled or disabled, or whether the device has asserted a message), and a crowd counting function needs to be evaluated to determine how many devices are enabled or have assertion information. Without a dedicated “crowd counting” instruction, this would likely require numerous shift and logic instructions to manipulate the register bits to generate a numerical count of the number of assertion bits, whereas some processing logic in the hardware can do so more efficiently in response to a single instruction if one of the custom codes is assigned to represent this operation. These are just a few possible examples, and custom operations are not limited to this.

[0066] like Figure 2As shown, many different types of custom instructions can be defined. For example, three custom instructions with different values ​​for opcode field 20 are provided to specify different numbers of source registers. The first custom instruction CX1 specifies a single register specifier Rd, whose identifier can optionally be used as the source register's destination register, and the remaining bits are used as the immediate field. The other custom instructions CX2 and CX3 define additional source registers Rn or Rm, which reduce the number of bits available for immediate field 22. It should be understood that this is only a subset of the examples of custom instructions that can be provided. Other variations can provide accumulation functions where, in addition to calculating the result value, the result value is then added to the previous contents of the destination register to produce the result, rather than simply overwriting the value in the destination register. Furthermore, some custom instructions can be interpreted to cause a source register reference to a particular register to not only result in the contents of that particular register being returned as the source operand of the instruction, but also to return the value stored in the next adjacent register, making the registers effectively referenced in odd / even pairs, which can increase the operand width of the custom instructions.

[0067] Although Figure 2 Three custom instructions CX1-CX3 are shown as examples of having opcode values ​​in adjacent portions of the opcode space, but this is not required, and any arbitrary encoding of the opcode field 20 can be assigned to the custom instructions.

[0068] For each custom instruction, the immediate field 22 can be used as another part of the opcode to distinguish which specific data processing operation should be performed. For example, the immediate field can specify that the operation of a given instruction should be a group counting function discussed above, or it should be a specific type of data format conversion. Therefore, Figure 2 The CX1 instruction shown corresponds to a single encoding of the opcode field 20 within the instruction set architecture to distinguish the instruction from other architecture-authorized instructions 24, but can control the processor to perform any of two or more different processing operations based on the value of the immediate field 22.

[0069] return Figure 1 , Figure 1The example of the processing system 2 shown divides the instruction decoder 4 and the execution circuitry 10 into a first part 40 and a second part 42 for processing architecture-granted instructions and custom instructions, respectively. For an architecture-granted instruction 24, when the instruction decoder 4 detects that the opcode field 20 represents one of these architecture-granted instructions, it passes the instruction to the regular execution circuitry 10 for execution using the value in register 8. Conversely, when the decoded instruction is one of the custom instructions, its instruction-encoded opcode field (opc) 20, its immediate value #imm 22, and any register values ​​44 required by the instruction are passed via an auxiliary execution interface 46 to an auxiliary decoder 48, which provides another part of the instruction decoder 4 to provide additional implementation-specific instruction decoding functionality required to distinguish which specific data processing operation is performed in response to a custom instruction. The auxiliary execution interface 46 is located within the first part 40 of the device and provides a signal path for outputting the instruction-encoded opcode 20, immediate value 22, and register value 44, and for returning the resulting value from the second part 42 to the write-back stage 12 to write back to register 8.

[0070] The second part 42 of the device includes an auxiliary decoder 48 and an auxiliary execution circuit 50, which includes hardware for executing custom data processing operations supported by custom instructions. The auxiliary decoder 48 selects which specific custom data processing operation the auxiliary execution circuit 50 should execute based on the opcode of the custom instruction. The auxiliary execution circuit 50 generates a result value, which is then passed back to the write-back stage 12 via the auxiliary execution interface 46 to be written back to the instruction's destination register.

[0071] Therefore, by separating the hardware logic used for decoding and executing custom instructions from the portion providing the architecture-licensed instructions into a separate part of the integrated circuit, system development can be simplified for implementers of data processing systems supporting custom instructions. This is because the circuit logic within the first part 40 can have a standard design provided by a microprocessor designer who designs the components and timing of the first part to suit the architecture-licensed functions of all processor-supported instruction set architectures. This standard design can define an auxiliary execution interface 46 for inputting and outputting values ​​exchanged with another part of the integrated circuit that can be designed to have specific custom functions. This allows the designer of the entire system to focus only on the second part 42 for implementing their custom functions and can reuse the off-the-shelf design of the first part 40.

[0072] like Figure 3As shown, an alternative approach to supporting custom instructions could be to provide device 2, where the auxiliary decoder 48 and auxiliary execution circuitry 50 are integrated into the instruction decoder 4 and the execution level 10 for handling architecture-authorized functions, thus eliminating the hard separation between architecture-authorized functions and custom functions. Therefore, the auxiliary execution circuitry 50 could resemble other execution units within execution level 10, such as an ALU, floating-point unit, or load / store unit, providing another functional unit that can be selected in response to instructions, without requiring a dedicated auxiliary execution interface 46 for custom instructions. The auxiliary instruction decoder 48 itself could be incorporated into the instruction decoder, allowing a common set of logic to decode both regular architecture-authorized instructions and custom instructions. This approach could be more efficient in terms of performance, as it is more efficient than... Figure 1 In cases where custom instruction codes are passed to separate parts of the circuit logic, it can allow for reduced circuit area and improved timing. However, Figure 3 This approach may require more development work from manufacturers of custom implementations, as it may not support features such as... Figure 1 The first part 40 of the existing logic may be used, but the entire processor design may need to be designed with appropriate components and circuit timing to implement the core architectural features and custom features required for that particular processor implementation.

[0073] Figure 4 The condition status register 36 is shown in more detail. The condition status register 36 can store multiple pieces of information about the processor's state, including information types not directly discussed in this application. However, a single piece of condition status information can be multiple condition status flags 60 indicating attributes of the result of a previously executed condition-setting instruction by the processor. For example... Figure 4 As shown in the example, condition status flag 60 may include four flags: a negative flag N indicating whether the result of the condition setting instruction is negative; a zero flag Z indicating whether the result of the condition setting instruction is zero; a carry flag C indicating whether the result of the condition setting instruction produces an overflow in an unsigned processing operation (i.e., a carry output from the most significant bit of the result); and / or an overflow flag V indicating whether the result of the condition setting instruction produces a signed overflow (i.e., a carry from the second most significant bit). Whether a particular instruction is a condition setting instruction may depend on the instruction-encoded opcode field 20, or on other opcode information such as that specified in the immediate field 22. Whether an instruction is a condition setting instruction may also depend on the opcode provided by the registers discussed below.

[0074] Certain types of instructions can be considered conditional instructions (whether an instruction is a conditional instruction depends on the opcode). For a conditional instruction, the instruction specifies, for example... Figure 4The test condition 70 is shown. A test condition specifies a condition that must be met by the condition flag 60 in the condition status register 36 in order to perform a corresponding data processing operation. For example, a conditional addition instruction can perform an addition operation if the condition is met, and leave the destination register unchanged if the condition is not met. Different condition values ​​in the condition field 70 can specify different conditions, such as requiring an operation to be performed if the previous result is negative or not negative. Different conditions can be defined for different combinations of the states of the corresponding condition flags.

[0075] Figure 5 This illustrates different ways that can represent opcodes and data operands of an instruction. An opcode is part of an instruction that selects which specific data processing operation to perform. Data operands are the values ​​processed within that specific data processing instruction. Figure 5 It is a table that shows which values ​​are used to identify the opcode and operand of architecture-granted instructions, custom instructions that are interpreted as non-register-provided opcode instructions (non-RPO instructions), and custom instructions that are interpreted as register-provided opcode instructions (RPO instructions).

[0076] For architecture grant instructions, the opcode is indicated by the instruction-encoded opcode (opc) 20, and optionally by the immediate value 22 (or a portion of the immediate value). Data operands are indicated by the source register of the instruction, depending on the number of registers encoded in the instruction; this source register may include the destination register Rd and / or one or more additional source registers Rn, Rm. If not used for the opcode, the data operand may also optionally be represented by at least a portion of the immediate value. Similarly, for condition instructions, the data operand may include the condition status flag (NZCV) 60 in the condition status register 36. Therefore, in this example, for architecture grant instructions, the opcode is identified entirely by the bits in the instruction encoding, and no register reads are required.

[0077] For user-defined instructions interpreted as non-RPO instructions, the opcode and data operands can be represented in exactly the same way as architecture-authorized instructions, except that at least a portion of the immediate value 22 is used to represent the opcode. This is because the instruction-encoded opcode opc 20 is used to distinguish the fact that the instruction is a user-defined instruction rather than an architecture-authorized instruction. The various registers Rd, Rn, Rm and condition status flag 60 are used only to identify the data operands of the operation; therefore, the selection of the specific data processing operation to be performed depends only on the portion of the opcode opc #imm directly encoded in the instruction encoding.

[0078] Conversely, for custom instructions interpreted as RPO instructions, in addition to the instruction-encoded portion of the opcode, which may include opcode field 20 and all or part of immediate field 22, the opcode also includes a first portion represented by register data stored in one or more source registers or condition status flags 60. Data operands are represented by a second portion of the register data stored in these registers and / or the remainder of the condition flags. Similarly, a portion of immediate field 22 may also be used as a data operand.

[0079] Designers of specific data processor implementations can arbitrarily choose which registers and which data portions within those registers are used for opcodes and which are used for specific partitions between data operands. Figure 1 In the example shown, the auxiliary execution interface 46 can simply pass the opcode value, immediate value, and register value, and the auxiliary decoder 48 can use these values ​​to determine which processing operation the auxiliary execution circuit 50 should perform. Figure 3 In the example, since the specific data processing operation to be performed may be unknown before the source value is read from the register, execution level 10 may have an auxiliary decoding circuit 48 to decode the value in the register, thereby distinguishing the different data processing operations to be performed.

[0080] The following describes some specific examples of RPO instructions. However, generally, by providing additional opcode bits using some register data, this increases the number of different data processing operations that a custom instruction can support. This is particularly useful when the opcode field 20 is already fully used to distinguish custom instructions from architecture-granted instructions, and when the number of bits available for custom instructions in the immediate field 22 is limited. This technique of using RPO instructions is for… Figure 2 The CX3 variant of the custom instruction shown is particularly useful, as it uses three different register specifiers, resulting in a very small number of remaining immediate bits 22.

[0081] Figure 6 A technique is shown that can be used to control the transfer of condition flags 60 from condition status register 36 to auxiliary instruction decoding logic 48, making them available for selecting data processing operations to be performed against custom instructions. Figure 2 The register specifiers Rd, Rn, and Rm shown in the example can be selected from a set of register specifier values ​​that correspond to a number of general-purpose registers in integer register file 30, floating-point register file 32, or some other general-purpose register file. Figure 6In the example, register files 30 and 32 are shown to include 16 registers, including a program counter register 34, which can be identified using a specific pc indicator value of a register specifier (register specifier 15 in this example). Therefore, in this example, the register specifier field can be a 4-bit register specifier identifying one of the 16 registers from register 0 to register 15, where register 15 indicates the program counter register 34. It should be understood that other examples may have a different number of registers and therefore a different number of register specifier bits.

[0082] However, typically the number of registers in the register file can be a power of 2, so all register identifiers can be assigned to specific general-purpose registers. Therefore, it is desirable that in order to be able to indicate what condition flag 60 should be passed to the auxiliary decoder 48, this would require allocating additional register specifiers, and thus additional bits in each register specifier field, but this would reduce the coding efficiency of custom instructions, as it would further reduce the number of immediate bits available for a given instruction length.

[0083] like Figure 6 As shown, it should be recognized that for RPO instructions, using program counter register 34 to provide the opcode represented by the first part of the register data of the RPO instruction is generally impractical. This is because the program counter register is typically used to control the flow of program execution, such that if the value in the program counter register changes, this will redirect the program flow to an instruction different from the one that follows sequentially with the previous instruction. This means that it is generally not possible to include an instruction that sets program counter register 34 to an arbitrary value to be used as part of the opcode for selecting data processing operations, simply before the RPO instruction, as this could interrupt the intended program flow. Therefore, in the selection logic 80 for customizing instructions to select which register to read to provide the source value of the instruction, the program counter indicates the register specifier (in... Figure 6 In the example, 15) may not represent the program counter register 34, but is used to select the condition status flag 60 from the condition status register 36, so that the condition flag can be passed as input to a custom instruction, and if the custom instruction uses these condition flags as opcode bits instead of the condition flags in an RPO instruction, the condition flags may be used as registers to provide opcodes.

[0084] like Figure 7 As shown, for a custom instruction whose opcode field 20 has a value indicating that it is one of the second subset of custom instruction values, one way to distinguish between non-RPO instructions and RPO instructions is to use the pre-defined bit 90 of the immediate field 22 to indicate whether the instruction is a non-RPO instruction or an RPO instruction.

[0085] Alternatively, other methods may not have dedicated bits indicating whether a portion of the opcode is stored in a register, but can simply use the combined value of the custom opcode field 20 and the immediate field 22 to determine whether a particular custom instruction should be considered a non-RPO instruction or an RPO instruction. Therefore, even among instructions with the same value for the custom opcode field 20 (in the encoding corresponding to the custom instruction), instructions with different values ​​for the immediate field 22 can have some instructions considered non-RPO instructions (the opcode is determined solely based on the bits of the instruction encoding) and others considered RPO instructions (at least one of the source register or condition flag 60 provides additional opcode bits).

[0086] Figure 8 An example of an RPO instruction is shown, for which the data value in the Rm source register is treated as a register-provided opcode. The Rm register is a general-purpose register selected from integer register file 30, floating-point register file 32, or another register file, not a system register. Therefore, the data in the general-purpose register referenced by the Rm register specifier provides additional opcode bits for the auxiliary execution circuitry 50 to select which particular transformation function should be applied to the data operands provided by the remaining source registers to produce the result value. For example, different transformation functions that can be selected based on bits from the data in register Rm can involve different arithmetic operations, logical operations, shift operations, or data conversion operations, or any combination or sequence of these operations. For the same instruction encoding, different transformation functions selectable for different values ​​of data in register Rn can include different transformations, each capable of producing a different value or a different data format for the result compared to the data input. Therefore, by providing the ability to select between different processing transformation functions using register values, this means that the range of options available to a custom implementation is greater than the range that can be encoded within the available encoding space of the instruction encoding itself. Note that the ability to use registers to provide opcode bits is particularly useful in custom implementations when, for a given set of opcodes and immediate fields 20 and 22, only some encodings require additional opcode space while others require the use of all register specifiers to specify data operands. Therefore, always using register data to provide data operands would limit the number of supported data processing operation types or the need for additional immediate bits. The ability to use register data as opcode bits increases the flexibility to balance the number of instruction variants relative to the number of required register operands on an instruction-by-instruction basis.

[0087] Figure 9 Another example of an RPO instruction is shown, where a condition flag is used to provide the opcode bit. This can be used... Figure 6The method shown allows the RPO instruction to specify the program counter indicator value as one of its source register specifiers, which enables the condition flags to be passed to the auxiliary decoder 48. The auxiliary decoder 48 uses the condition flags in combination with the opcode field and immediate fields 20, 22 to select the transformation function to be applied to the data operand 100 by the auxiliary execution circuitry 50 to generate the result.

[0088] Although Figure 8 and 9 The example illustrates the use of register data or condition flags as opcode bits, but other methods may combine them for opcode bits. Similarly, it is not mandatory to use all bits or all condition flags in the source register Rm as opcode bits, and any remaining bits not used to provide the opcode can be used as data operands. Likewise, some methods may use multiple registers to provide different portions of the opcode.

[0089] like Figure 10 As shown, for another variant of the RPO instruction, the register provides the opcode to select from which register file the other source operands are read (e.g., between integer register file 30 and floating-point register file 32), rather than selecting which transformation function should be applied by the auxiliary execution circuitry. Figure 1 In the method described, where the auxiliary decoder 48 selects the register based on the register-provided opcode, registers from two register files 30 and 32 can be read for each custom instruction and provided by the auxiliary execution interface 46. Alternatively, once the selector logic 102 has selected the appropriate register file 30 or 32 to be read, the source register providing the register-provided opcode can be read first, and then the remaining registers to be used as data operands can be read in subsequent cycles. Similarly, Figure 10 The method shown can be used with Figure 8 and Figure 9 The combination of methods allows for the selection of the register file to be used for the source input and the transformation function to be applied, based on the opcode provided by the register.

[0090] It should be understood that the examples discussed above are merely some examples of how values ​​in the general or condition code register can be used to select which data processing operation to apply.

[0091] Figure 11This is a flowchart illustrating a method for processing instructions in data processing device 2. In step 200, instruction decoder 4 decodes the instruction. In step 202, instruction decoder 4 determines whether the instruction is a register-provided opcode instruction based on the instruction encoding of the instruction (e.g., based on the opcode and immediate fields 20, 22). If so, in step 204, instruction decoder 4 determines that the opcode of the instruction is represented by an instruction-encoded opcode, which is directly specified by the instruction encoding of the instruction. The instruction-encoded opcode may include at least a portion of the opcode field 20 and the immediate value 22. Furthermore, a portion of the opcode is represented by a first portion of source register data stored in at least one source register specified by the instruction. The instruction(s) data operands are represented by a second portion of the source register data of the instruction, and optionally, if a portion of the immediate field is not used to represent the opcode, it may also be represented by a portion of the immediate field.

[0092] On the other hand, if the instruction is not a register-provided opcode instruction, then in step 206, it is determined that the opcode is represented by instruction-encoded opcodes 20 and 22. In this case, the data operands of the instruction are represented by source register data in any source register of the instruction (optionally including condition status flag 60), and in some cases, the immediate value may be used at least partially to represent the data operands. For non-RPO instructions, in some cases, the immediate value 22 may not be used at all to represent the opcode, but may only represent the data operands, while in other cases, the immediate value 22 may be used at least partially to represent the opcode.

[0093] Regardless of whether the instruction is an RPO instruction, in step 208, the instruction decoders 4 and 48 select which data processing operation should be performed based on the opcode identified in one of steps 204 and 206. Different data processing operations can vary depending on the specific set of arithmetic, logical, shift, or transformation functions executed, or on which register file the source operand is fetched from. In step 210, the control execution circuits 10 and 50 execute the data processing operation selected in step 208 on the data operand identified in step 204 or 206 to generate a result value that can be written back to the destination register. In some cases, the register file containing the destination register can also be selected based on the opcode.

[0094] Figure 12Emulator implementations that can be used are illustrated. While the embodiments described above implement the invention in terms of devices and methods for operating specific processing hardware that supports the relevant technologies, instruction execution environments according to the embodiments described herein can also be provided, implemented using computer programs. Such computer programs are generally referred to as emulators whenever they provide a software-based implementation of a hardware architecture. Various emulator computer programs include simulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, emulator implementations can run on a host processor 330, optionally running a host operating system 320 that supports the emulator program 310. In some arrangements, multiple emulation layers may exist between the hardware and the provided instruction execution environment and / or between multiple different instruction execution environments provided on the same host processor. In the past, powerful processors were required to provide emulator implementations that executed at a reasonable speed, but this approach may be reasonable in certain situations (e.g., when it is desirable to run code native to another processor for compatibility or reuse reasons). For example, emulator implementations may provide instruction execution environments with additional functionality not supported by the host processor hardware, or instruction execution environments typically associated with different hardware architectures. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques” (USENIX Winter 1990 Conference, Robert Bedichek, pp. 53-63).

[0095] With respect to embodiments previously described with reference to specific hardware constructions or features, equivalent functionality may be provided by suitable software constructions or features in simulated embodiments. For example, specific circuitry may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in simulated embodiments. In arrangements where one or more hardware elements referenced in the previously described embodiments are present on host hardware (e.g., host processor 330), some simulated embodiments may utilize the host hardware where appropriate.

[0096] The simulator program 310 can be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 300 (which may include applications, operating systems, and management programs). This program interface is identical to the application program interface of the hardware architecture modeled by the simulator program 310. Therefore, the simulator program 310 can be used to execute program instructions of the target code 300, including the aforementioned RPO instructions, from within the instruction execution environment, enabling a host computer 330, which does not actually possess the hardware features of the aforementioned device 2, to simulate the behavior of the target processor 340, which does possess these features.

[0097] For example, the emulation program 310 may include instruction decoding program logic 312, which provides functionality equivalent to the instruction decoders 4 and 48 of the aforementioned hardware device 2. The instruction decoding program logic 312 decodes the instructions of the target program 300 and maps them to corresponding instruction sets in the local instruction set supported by the host processor 330, which controls the host processor 330 to execute the required functions. The emulation program 310 includes register emulation program logic 314, which maintains a register emulation data structure 316 in the memory of the host processor 330, and the host processor 330 tracks the register states that would be stored in register 8 if the target program 300 is executed on the aforementioned hardware device 2. Therefore, when the target program 300 includes an RPO instruction, the instruction decoding program logic 312 decodes the RPO instruction, and the register emulation program logic 314 controls the host processor 330 to read the register-provided opcode from the storage location in the register emulation data structure 316. The instruction decoding program logic 312 uses the register-provided opcode and the instruction encoding part of the opcode to determine which processing operations the host processor 330 should perform in order to emulate the function of the RPO instruction.

[0098] In this application, the phrase "configured as..." is used to indicate that the elements of a device have a configuration capable of performing the defined operations. In this document, "configuration" refers to the arrangement or manner of interconnection of hardware or software. For example, the device may have dedicated hardware that provides the defined operations, or a processor or other processing device may be programmed to perform that function. "Configured as" does not imply that the device elements need to be changed in any way to provide the defined operations.

[0099] While illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to these precise embodiments, and that various changes and modifications may be made therein by those skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. A data processing device, comprising: Multiple registers are used to store data; Processing circuitry for performing data processing using data obtained from the register; as well as An instruction decoder is used to decode an instruction with a specified opcode and at least one data operand to control the processing circuit to perform a data processing operation identified by the opcode on the at least one data operand to generate a result value to be written to a destination register. Specifically, opcode instructions are provided for registers that specify at least one source register: At least a portion of the opcode is represented by a register-provided opcode, which is a first portion of the data stored in the at least one source register that provides the opcode instruction. The at least one data operand includes data represented by a second portion of data stored in the at least one source register; In response to an opcode instruction provided by the register, the instruction decoder is configured to control the processing circuitry to select, at least based on the opcode provided by the register, one of several different data processing operations supported by the same instruction encoding for the opcode instruction provided by the register; and The plurality of different data processing operations include at least two different data processing operations, which, for at least one subset of the possible input values ​​of the at least one data operand, are both capable of generating a result value having a value or data format different from that of the at least one data operand.

2. The device according to claim 1, wherein, The at least two different data processing operations include at least two different transformation functions for generating the result value from the at least one data operand.

3. The device according to claim 2, wherein, Each of the at least two different transformation functions includes one or more different subsets or combinations of the following: At least one arithmetic operator; At least one logical operator; At least one shift operator; as well as At least one data format conversion operator.

4. The device according to any one of claims 1 to 3, wherein, The register includes at least two register files; and The at least two different data processing operations include: using different register files to provide at least one source register for storing the at least one data operand or a destination register for storing the result value.

5. The device according to any one of claims 1 to 3, wherein, The register provides an opcode represented by data stored in at least a portion of a general-purpose register designated as one of the at least one source registers.

6. The device according to claim 5, wherein, The register provides opcode instructions to specify multiple source registers. The at least one data operand is represented by data stored in one or more of the source registers, rather than by data stored in the general-purpose registers used to provide opcodes for the registers, and The at least one data operand is independent of the data in the general-purpose register used to provide the opcode for the register.

7. The device according to claim 1, wherein, The register includes a condition status register for storing at least one condition indicator; In response to a conditional instruction, the instruction decoder is configured to control the processing circuitry to perform a conditional operation, the conditional operation depending on whether the at least one conditional indicator satisfies the test condition specified by the conditional instruction; and The register provides an opcode represented by at least a portion of the at least one condition indicator stored in the condition status register.

8. The device according to claim 7, wherein, The condition status register is configured to store a plurality of condition indicators, and the register provides an opcode represented by the aggregate of the plurality of condition indicators.

9. The device according to claim 7, wherein, The condition status register is configured to store multiple condition indicators; and The register provides an opcode represented by a first subset of the plurality of condition indicators.

10. The device according to claim 9, wherein, The opcode instruction provided by the register is a condition register opcode instruction, and for at least one of the plurality of different data processing operations of the condition register opcode instruction, the data processing operation depends on whether the remaining subset of the plurality of condition indicators satisfies the test condition specified by the condition register opcode instruction.

11. The device according to any one of claims 7 to 10, wherein, In response to a condition setting instruction, the instruction decoder is configured to control the processing circuit to execute the data processing operation represented by the opcode of the condition setting instruction, and to update at least one condition indicator stored in the condition status register based on the attributes of the result of executing the data processing operation.

12. The device according to any one of claims 7 to 10, comprising a program counter register for storing a program counter indicating the address of an instruction representing the current point of program execution; For a given instruction other than the one whose opcode is provided by the register, when the source register identifier specified by the given instruction has a predetermined program counter register indication value, at least one data operand of the given instruction includes a program counter stored in the program counter register; and When the register provides an opcode instruction specifying a source register identifier having the predetermined program counter register indication value, the at least one source register includes the condition status register.

13. The device according to any one of claims 1 to 3, wherein, The register provides an opcode instruction specifying multiple source register identifiers that indicate multiple source registers, and the register provides an opcode that is stored in at least one of the multiple source registers.

14. The device according to any one of claims 1 to 3, wherein, The instruction encoding provided by the register for the opcode instruction also specifies an immediate value representing another portion of the opcode instruction provided by the register; and In response to the opcode instruction provided by the register, the processing circuitry is configured to select a data processing operation based on both the immediate value and the opcode provided by the register.

15. The device according to any one of claims 1 to 3, wherein, For non-register instructions that specify at least one source register: The opcode is represented by a portion of the instruction encoding of the non-register-provided opcode instruction; and The data in the at least one source register is used as the at least one data operand, but not as part of the opcode; and For the portion of the instruction encoding, the register-provided opcode instruction and the non-register-provided opcode instruction have different encodings.

16. The device according to any one of claims 1 to 3, wherein, A portion of the opcode for each instruction is specified by the instruction-encoded opcode represented in a predetermined portion of the instruction encoding; The first subset of instructions having the values ​​of the instruction-encoded opcode are not instructions whose opcodes are provided by the register; and For a second subset of instructions having the value of the instruction-encoded opcode, an immediate value specified in another part of the instruction encoding, different from the instruction-encoded opcode, specifies another part of the opcode, and the register-provided opcode instruction is an instruction in the second subset of instructions, for the second subset of instructions, the instruction-encoded opcode and the immediate value have one of a predetermined subset of values.

17. The device according to any one of claims 1 to 3, wherein, The processing circuitry is configured to process instructions according to a given instruction set architecture; and The register provides opcode instructions that are custom instructions with encodings defined in the given instruction set architecture. For the custom instructions, the plurality of data processing operations include implementation-specific custom data processing operations that are not specified by the given instruction set architecture.

18. The device according to claim 17, wherein, Whether the given encoding of the custom instruction is decoded into an instruction with an opcode provided by the register or into an instruction with an opcode provided by a non-register is not determined by the given instruction set architecture.

19. A data processing method, comprising: Decode an instruction that specifies an opcode and at least one data operand to control the processing circuitry to perform a data processing operation on the at least one data operand identified by the opcode, in order to generate a result value to be written to a destination register; as well as When the instruction being decoded is an opcode instruction that specifies at least one source register: At least a portion of the opcode is represented by a register-provided opcode, which is a first portion of the data stored in the at least one source register that provides the opcode instruction. The at least one data operand includes data represented by a second portion of data stored in the at least one source register; In response to an opcode instruction provided by the register, the processing circuitry selects one of a plurality of different data processing operations supported by the same instruction encoding for the opcode instruction provided by the register, based at least on the opcode provided by the register. The plurality of different data processing operations include at least two different data processing operations, which, for at least one subset of the possible input values ​​of the at least one data operand, are both capable of generating a result value having a value or data format different from that of the at least one data operand.

20. A computer program product, comprising a computer program for controlling a host data processing device to simulate the processing of a target program by a target processing circuit, the computer program comprising: The register simulation program logic is used to maintain the register simulation data structure of multiple registers of the target processing circuit being simulated; as well as The instruction decoding program logic is used to decode the instruction of the target program with a specified opcode and at least one data operand, so as to control the host data processing device to perform a data processing operation identified by the opcode on the at least one data operand, so as to generate a result value to be written into a part of the register simulation data structure corresponding to the destination register in the plurality of registers; Specifically, opcode instructions are provided for registers that specify at least one source register: At least a portion of the opcode is represented by a register-provided opcode, which is a first portion of the data corresponding to at least one source register that provides the opcode instruction to the register. The at least one data operand includes data represented by a second portion of data corresponding to the at least one source register; In response to an opcode instruction provided by the register, the instruction decoding logic is configured to control the host data processing device to select, at least based on the opcode provided by the register, one of several different data processing operations supported by the same instruction encoding for the opcode instruction provided by the register; and The plurality of different data processing operations include at least two different data processing operations, which, for at least one subset of the possible input values ​​of the at least one data operand, are both capable of generating a result value having a value or data format different from that of the at least one data operand.

21. A computer-readable storage medium storing a computer program according to claim 20.

Images