The present invention relates to a processor for processing data of multiple sizes.
A built-in processor now needs to process data of various sizes, e.g., 8-, 16- and 32-bit data, by itself. However, when applied to a mobile unit, a processor also needs to reduce its power dissipation as much as possible such that the processor can be driven for a longest possible time using a battery with a limited capacity.
A known RISC (reduced instruction set computer) processor with 32-bit architecture includes: a 32-bit arithmetic and logic unit (ALU) for performing arithmetic and logical operations on data; a 32-bit register file for retaining data therein; and a 32-bit bus for transferring data therethrough. In manipulating 8-bit data, the processor of this type extends the size of the data into 32 bits unconditionally. More specifically, if the 8-bit data in question is signed, then sign extension is carried out on the high-order 24 bits. Alternatively, if the 8-bit data is unsigned, then zero extension is carried out on the high-order 24 bits. Similarly, in manipulating 16-bit data, the processor of this type also extends the size of the data into 32 bits unconditionally. In the conventional processor, the 32-bit data obtained in this manner is provided to the 32-bit ALU and retained in the 32-bit register file or transferred through the 32-bit bus.
Even in performing a series of operations, like loading two 8-bit data elements from a memory, adding these data elements together and then storing 8-bit data representing the sum in the memory, the RISC processor should use all of its hardware resources, i.e., the 32-bit ALU, 32-bit register file and 32-bit bus. Thus, the processor dissipates power in vain. The same problem arises when the processor handles 16-bit data.
It is therefore an object of the present invention to cut down on the power dissipated wastefully by the multi-size data compliant processor.
To achieve this object, the inventive processor for handling data of multiple sizes is so constructed as to enable only a part of manipulation means that has a bit width corresponding to a maximum one of those sizes and that is associated with the data size of a specified operand. As used herein, the xe2x80x9cmanipulation meansxe2x80x9d is means for performing an operation, specified by an instruction, on an operand that has also been specified by the same instruction. The manipulation means includes: an ALU for performing arithmetic and logical operations on operand data; a register file for retaining the operand data therein; a bus for transferring the operand data therethrough; a driver for driving the bus; a latch for latching the operand data from the bus; and an extender for extending the size of the operand data. For example, by decoding a given instruction, size information about the data size of the operand specified by the instruction is obtained, thereby enabling only a part of the manipulation means that is specified by the size information.
To implement object-oriented architecture, operand data and size information about the size of the operand data are preferably retained in the register file. In this case, if a first instruction decoded requests that operand data of a particular size be written on the register file and if size information about the data size of the operand, specified by the first instruction, has been obtained, then not only the operand data but also the size information are retained in the register file. Alternatively, if a second instruction decoded requests that the operand data retained in the register file be referred to, then size information about the size of the operand data, as well as the operand data itself, are read out from the register file, thereby enabling only a part of the manipulation means that is specified by the size information read out from the register file.
According to another aspect of the present invention, the first instruction may also be an instruction specifying whether the operand data should be handled as signed data or unsigned data. The register file preferably retains the sign information representing whether the operand data is signed or unsigned, in addition to the operand data and the size information about the size of the operand data. In this case, if the sign information representing whether the operand, specified by the first instruction, is signed or unsigned is obtained in accordance with the first instruction decoded, then the register file retains not only the operand data but also the sign information. Alternatively, if the second instruction decoded requests that the operand data retained in the register file be referred to, then the sign information representing whether the operand data is signed or unsigned, as well as the operand data itself, are read out from the register file, and the manipulation means is controlled such that the second instruction is executed in accordance with the sign information read out.