JP2003532221A - Processor architecture with ALU, Java stack and multiple stack pointers - Google Patents

Abstract

SUMMARY A stack-based processor mechanism and associated method for processing data through a processor is provided. The first data to be processed is written to the operand stack. The data position in the operand stack is specified using a stack pointer included in the stack / ALU controller of the stack processor. The stack pointer specifies a bank in the operand stack where data is to be stored. After the data position is specified, the selected data is transferred in parallel using the stack pointer and the function code. The selected data is transferred from the operand stack to a logical operation unit that performs a process according to the instruction specified by the function code. Thereafter, the result is efficiently returned to the operand stack and read when desired.

Description

Detailed Description of the Invention

TECHNICAL FIELD The present invention relates to an execution unit inside a Java (registered trademark) stack-based processor. More specifically, the present invention relates to data processing by a stack processing hardware configuration that transmits and receives data more efficiently between a processing unit and a storage unit.

2. Description of the Related Art When computer processors flood the market, there is an increasing demand for processors with higher processing performance. Today's processors handle more complex tasks that require faster processing speeds. Moreover, these complex tasks require a processor that more efficiently exploits the performance of internal storage. A known processor performs a logical operation on the data taken out from the operand stack. As one of this kind of stack-based processor, Java Virtual Machine (J
VM). The JVM is a common form of computer model that implements the Java language. While the JVM works well for less demanding applications, implementing some of the JVM in hardware requires improved performance. That is, the stack processor was implemented in hardware, but the implementation was not efficient in response to the increasing demand for processing performance. For example, a typical stack-based processor has a 32-bit or 64-bit wide stack.

If a 32-bit wide stack-based processor is utilized and there is a request to write a 64-bit wide entry, then two accesses are required to read the data from the operand stack into the ALU. Two accesses are required to write the result back to the stack. Ie, three times to read the data from the stack
A 2-bit read is required and two additional 32-bit writes are required to write the data back to the stack. If a 64-bit wide stack-based processor has two sets of 64-bit wide data, a total of four accesses are required until the data is read from the stack and the result is stored in the operand stack. This means that two sets of 64 bits are required to read the data from the operand stack and two sets of 64 bits are required to store the result in the operand stack. Therefore, the multiple accesses required to process data on current stack-based processors increases the overall processing time of the data and reduces the overall efficiency of implementations using stack-based processors. .

Also, current 64-bit wide stacks do not allow efficient allocation of data that is 64 bits wide or less. For example, 32-bit wide data can occupy a stack storage area column that can hold 64 bits. That is, the remaining 32 bits in the column can be wasted. Therefore, this type of implementation wastes expensive storage space and is highly undesirable.

In addition to the stack-based processor described above, there are currently three basic techniques to improve performance, full hardware interpretation of Java instructions, native Java and compilation. The hardware interpretation approach utilizes hardware to improve the interpretation process. The host hardware translates the Java instructions into machine language. The translated machine language is compatible with industry standard processors of hardware modeling Java machines. This has two functional problems. First, it takes time regardless of whether the translation is done by software interpretation (typical situation) or hardware translation. Once the result is produced, the translation has to be performed. Thus, hardware translation is a two step process (ie, translation after execution). The second issue associated with Java hardware translation is architecture. If the target processor is (
Unless you have a stack-based machine (like most machines), the translation process is complicated. As a result, each Java instruction evolves into multiple target processor instructions so that an artificial (ie, virtual) stack can be emulated.

A pure Java processor produces a real stack-based processor in hardware. However, real stack-based processors are very complex and do not take advantage of most of the software available on standard processors (eg ARM, MIPS and x86).

Compilation is another technique that improves performance. Compile does not require an interpreter and compiles Java directly into a specific machine language. Nevertheless, the resulting executable is not small. The resources required to perform a Java compilation are expensive and sometimes inconvenient (eg, handheld personal digital assistants and cell phones do not have enough memory to support the compiler). Moreover, the time required to perform the compilation causes an excessive initial delay (ie, real-time response is not needed at startup).

From the above viewpoint, a stack-based processing mechanism that solves the problems of the conventional technology is required. Further, the disclosed mechanism and related techniques allow for efficient use of storage space within the operand stack while eliminating the problems of the prior art.

DISCLOSURE OF THE INVENTION Broadly speaking, the present invention satisfies the above need by providing a method and hardware for efficiently processing data using a stack-based processor. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device and a method. Several inventive embodiments of the present invention are described below.

In one embodiment, a technique for processing data via a stack processor is disclosed. This technique writes data to the operand stack and identifies the data location within the operand stack. Data locations within the operand stack are identified using one or more stack pointers. When the stack pointer positions the data in the operand stack, the data is transferred in parallel to the logical operation unit. The transferred data is selected using the stack pointer or the function code. The transferred data is processed in the logical operation unit according to the instruction defined by the function code.

In another embodiment, a stack processing subsystem for processing data is disclosed.
The stack processing system has an operand stack located within the stack processing subsystem. This operand stack has banks capable of storing data. The stack processing subsystem also has a stack pointer that identifies a data location within a bank of the operand stack. The logical operation unit is an interface with the operand stack, and parallel word transfer of data can be performed from the operand stack to the logical operation unit. Further, the data to be transferred by the parallel word transfer is specified by using the stack pointer and the function code. The function code identifies the particular instruction processed by the logical operation unit.

[0012] In another embodiment, a method of performing processing on data using a stack pointer is disclosed. This data is placed on the operand stack contained within the stack processor. The data position in the operand stack is tracked by the stack pointer, which is also located in the stack processor. After the data is placed in the operand stack, the data is transferred from the operand stack to the logical operation unit. This data can be transferred from the operand stack to the logical operation unit in 128 bit increments. When the data is transferred to the logical operation unit, the data is processed by the instruction from the function code.

One should appreciate the many advantages of the present invention. In one embodiment of the present invention, the operand stack and the logical operation unit are combined into a single unit. Further, the present invention allows for more efficient use of 128 bits wide by dividing the stack into banks. In the past, when less than the stack's data width was stored on the stack (ie, 32-bit data in a 64-bit stack), the remaining space was wasted (ie, the remaining 32-bits in the 64-bit stack). The data was wasted wastefully). In the present invention, the stack pointer is the same for a plurality of data as compared with the case where data is arranged for each column (that is, two sets of independent 64-bit entries are arranged for each 128-bit column). Place in columns (two independent 64-bit entries in the same column).
The present invention also allows 128-bit wide data to be fully processed with only two accesses in a single arithmetic operation (ie, one read access and one write access). Thus, the processing time of Java's stack-based processor is very short because the disclosed and claimed structures and methods allow for less access to data and efficient processing.

Other features and advantages of the present invention are described in detail below with reference to the accompanying drawings that illustrate the principles of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION The present invention can be easily understood by the following detailed description in conjunction with the accompanying drawings. The same components are designated by the same reference numerals.

Integrated stack / ALU for processing data using stack subsystem
Mechanisms for subsystems and related methods are disclosed. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, one of ordinary skill in the art will appreciate that the present invention may be practiced without some or all of these specific details. In other instances, well-known processing operations have not been described in detail so as not to unnecessarily obscure the present invention.

FIG. 1 is an external view of a Java stack subsystem 102 that is an embodiment of the present invention.
00 is shown. The Java stack subsystem 102 is an execution unit for a Java processor. The Java stack subsystem 102 has a 32-bit wide bus 120 that communicates with the system bus 150 with other subsystems. In one embodiment, bus 120 may provide the data to be loaded into input multiplexer (input mux) 108. Input mux 108 directs 32-bit data from bus 120 to operand 110.

To load data into operand stack 110, stack / ALU controller 104 decodes function code 124. The function code 124 is
It provides the stack / ALU controller 104 with information regarding what processing should be performed on the data stored in the operand stack 110. For example, function code 124 may require an ADD operation to be performed on a given data set. In this case, function code 124 causes logical operation unit (ALU) 106 to perform an ADD operation on the data to be read from operand stack 110. Therefore, the function code 124 causes the stack pointers 105c-f (that is, the stack pointer-1, the stack pointer-2, the stack pointer-3, and the stack pointer-4) to specify the desired data position in the operand stack 110. The desired data is retrieved by ALU 106 by output multiplexer 112 using a 128 bit wide bus. As such, data from each part of the operand stack 110 (eg, each 32-bit part) is transferred to the ALU during a single access.
Can be read by 106.

Operand stack 110, in one embodiment, has four banks 110a-110d. Each bank 110 is preferably 32 bits wide. Stack pointer 105 is 3
It is 2-bit centric and is used to select which of the banks 110a-110d of the operand stack 110 will receive the data and which of the banks 110a-110d will pass to the ALU 106. Stack pointers 105c-f identify the data locations for the last four entries pushed onto operand stack 110.

In the preferred embodiment, the stack / ALU controller 104 controls all operations and operates all functionality within the stack / ALU subsystem 102. The stack / ALU controller 104 has six stack pointers 105 that allow flexible and efficient access to the stack. Stack pointer 105a (
Stack pointer +1) and stack pointer 105b (stack pointer) are defined by stack pointers 105c-f. (Stack pointer +1) 105a is the stack +1
Is the start address of. The stack pointer 105b is always the top address of the stack. The stack pointers 105c-f are respectively stack-1, -2, -3 as described above.
, -4 is the start address. During access, the stack pointers 105c-f can each define which one or all banks 110a-d should be gated. As a result, the ALU 106 can have all four banks 110a-110d gated to a 128-bit wide bus during a single access cycle. Thus, the stack / ALU subsystem 102 does not waste time by reading only one 32-bit entity per cycle and then adjusting the stack pointer to read the next 32-bit entity.

Further, a bus master interface unit (BMIU) 130 is connected to the bus 120. The BMIU 130 communicates between the system bus 150 and the stack / ALU subsystem 102. For example, the BMIU 130 can control addressing 142 and read / write 144 to the stack / ALU subsystem 102. Also shown are the Halt 145 commands that may be communicated with the Stack / ALU subsystem 102. A read / write stack (RD / WRT STK) 126 is also shown to communicate with the stack / ALU subsystem 102. RD
/ WRT STK 126 is identified in one example by the function code discussed with reference to FIG. The RD / WRT STK 126 permits the host processor to read and write from the operand stack 110. In addition, the wait 136 command and ALU CC (status code) 134 are shown as signals from the stack / ALU subsystem 102. Bus 140 takes the output from output 116 along path 132 to BMIU 130.

The following is an example of efficient operation of the stack / ALU subsystem 102 for understanding purposes. First, 32-bit wide data is sent to the stack / ALU subsystem 102 via the bus 120. The stack pointers 105c-f guide the 32-bit data to the banks 110a, 110b, 110c, 110d, respectively. As an example, AD
The function code 124 defining the D operation is directed to the stack / ALU controller 104 where the function code 124 is decoded. Stack / ALU controller 1
After 04 decodes the function code 124, the first cycle begins. In the first cycle, the stack / ALU controller 104 directs the data from the operand stack 110 to the ALU 106 via the output mux 112. In one preferred embodiment, the data derived from output mux 112 to ALU 106 is 128 bits wide (
For example, multiple 32-bit words). This is the opposite of the conventional example of transferring data in 32-bit width increments (eg, only one word at a time), and transfers of 32 bits or more use many cycles without using the stack pointer. Done.

Stack / ALU controller 104 when data is directed to ALU 106
Transfers the function code to the ALU 106. As such, the ALU 106 performs the desired operation specified by the function code 124 of the data to produce the result (e.g., the operation may be a computing operation commonly performed by a processor, Java processor, etc.). The ALU 106 sends a signal to the stack / ALU 104 indicating that the operation is completed, and the stack / ALU controller 104 sends the signal to the ALU1.
The result from 06 is read and returned to the operand stack 110. The return path 114 from the ALU 106 to the operand stack 110 is specified by two types of 32-bit width paths 114a and 114b (that is, 64-bit width paths). This ensures that the result can be stored during the same single access operation. When the result is written back to operand stack 110, stack pointer 105e (stack pointer-3) and stack pointer 105f (stack pointer-4) locate the result within operand stack 110.

The stack pointer 105 is readjusted after the result is read back into the operand stack 110 in the second cycle. The stack pointers are stack pointer 105c (stack pointer-1) and stack pointer 105d (stack pointer-2).
) Is readjusted to indicate the data position. Note that the data position within operand stack 110 does not change. The instruction to realign the stack pointer is part of the function code 124. When the user reads the result stored in the operand stack 110, the output mux 112 spits out a 32-bit wide result. The instruction that flushes the result from the operand stack 110 is written into the function code 124 and is part of the standard Java code. The information retrieved from the Java stack is generally done under the control of the POP instruction. The function code is sent to the stack / ALU subsystem 102 by the decode / execute subsystem. When the function code is sent to the stack / ALU subsystem 102, it gates the appropriate data in the operand stack 110 on the B bus.

FIG. 2 is an embodiment of the present invention showing the stack pointer 105 for transferring data from the operand stack 110 to the ALU slots 112a-d. The function code register 202 holds the operation to be performed by the stack / ALU subsystem 102. This information is derived from Java instructions by the decode / execute subsystem. The decoding / execution subsystem is the stack / ALU subsystem 10
Communicate with 2. Its function is known to those skilled in the art. In one embodiment, the function code requires that it be performed on the data in the operand stack 110. For example, when the ADD operation is requested, the function code register 202 is written so as to instruct the ADD operation. Function code register 202 is shown in communication with function decode table 204. In one embodiment,
The function code table 204 includes a decoded signal (for example, ADD or long division).
Have. Thus, these decode signals 204a identify the function to be performed, in one embodiment.

The function decode table 204 transfers the decode signal 204a to the bank selector mux2.
It is transmitted to 06. The stack pointer 105 transfers the bank address information of the data in the operand stack 110 to the bank selection mux 206. Stack pointer 105 includes address bits 105c-1 to 105f-1 that specify the bank address of the data in operand stack 110. The bank selector 206 acquires the information from the decoded signal 204a, and the address bits 105c-1 to 105f-1 generate the slot selection signal 206a. Slot select signal 206a associates data sent for processing by ALU 106 with ALU slots 112a-d of output mux 112.
The slot select signal 206a also informs the input mux 108 of the target position within the operand bank 110 containing the ALU operation result. Data is operand stack 110
Note that it will come from any of the banks 110a-d, regardless of their order in which they are present.

For purposes of understanding, an example operation of transferring data from operand stack 110 to ALU slots 112a-d, as discussed with reference to FIG. 2, is described below. For example, a Java instruction specifies that an ADD operation is performed on the data set contained within operand stack 110. Decoding a Java instruction causes the function code to request the ADD instruction to be loaded.

After the function decode table 204 is accessed, the decode signal 204 a is generated and sent to the bank selection mux 206. Furthermore, the stack pointer 105 is
Send information indicating the bank address of the data in operand stack 110.
For example, the stack pointer 105f is the requested AD with address bits 105f-l.
Identify the bank position of the data set for the D instruction. The bank selector mux 206 is
It produces a slot signal 206a and sends this signal to the output mux 112. Slot signal
206a informs the output mux of the bank address of the data set.

As mentioned above, the present invention offers many advantages to the user. The present invention is implemented with a stack processor with fewer accesses and more efficiently.
At most, two accesses, read and write, are required. The data path from the operand stack to the ALU is 128 bits wide and two sets of 64 bit entries are read in a single access. Previously, the datapath was either 32 or 64 bits wide. In either case, the ALU for 128-bit entity needs to be accessed multiple times to read data from the operand stack, resulting in an increase in processing time.

In addition, the stack pointer prevents wasting expensive storage space in the stack. The stack pointer creates a selectable bank, which creates a 32-bit wide storage area in a 128-bit wide stack. Thus, a 128-bit wide stack can store up to four 32-bit wide independent data entries. Compared to the prior art, one 32-bit data entry does not waste the storage space in the 128-bit wide stack, which allows the storage space of the stack to be used more efficiently.

The present invention can be implemented using computer-implemented operations driven by suitable software. Thus, various computer-implemented operations involving data stored within a computer system (ie, in the form of software drivers) for driving computer peripherals are applicable. These operations require physical manipulations of physical quantities. Usually, though not necessarily, these physical quantities require the form of electronic or magnetic signals that can be stored, transmitted, combined, compared, and manipulated. Further, the manipulations performed are often referred to in the periods to confirm, identify, scan, or compare.

Some of the operations described above that form part of the present invention are beneficial to machine operation.
Appropriate devices or apparatus may be available to perform these operations. The device may be a general purpose computer specifically configured for the required purpose or selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with the computer programs described in accordance with the above description. This kind of machine
It is more convenient to configure a more specialized device to perform the required operations.

Although the above invention has been described in detail for the sake of clarity, it will be apparent that certain changes and modifications are possible within the scope of the appended claims. Therefore, this embodiment is schematic and not limiting. The present invention is not limited to the above detailed description, and various modifications can be made within the scope of the appended claims and the equivalents thereof.

The invention may also be implemented using computer-implemented operations driven by suitable software. Thus, various computer-implemented operations involving data stored within a computer system (ie, in the form of software drivers) for driving computer peripherals are applicable. These operations require physical manipulations of physical quantities. Usually, though not necessarily, these physical quantities require the form of electronic or magnetic signals that can be stored, transmitted, combined, compared, and manipulated. Further, the manipulations performed are often referred to in the periods to confirm, identify, scan, or compare.

Some of the above-described operations that form part of the present invention are beneficial to machine operation.
Appropriate devices or apparatus may be useful for performing these operations. The device may be a general purpose computer specifically configured for the required purpose or selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with the computer programs described in accordance with the above description. This kind of machine
It is more convenient to configure a more specialized device to perform the required operations.

[Brief description of drawings]

[Figure 1]   FIG. 3 illustrates a Java stack subsystem according to one embodiment of the present invention.

FIG. 2 is a diagram of one embodiment of the present invention showing a stack pointer that directly transfers data from the operand stack to a particular ALU slot.

─────────────────────────────────────────────────── ─── Continued front page    (72) Inventor David Earl. Evoie             Tempe, Arizona, United States             Strike, secretariat, drive, 68 (72) Inventor Satiendra, S. Cecie             Preza, California, United States             Tone, enthusiast, wood, drive,             5179 F-term (reference) 5B033 DE00

Claims (24)

[Claims] 1. A method of processing data through a stack processor, comprising writing data to an operand stack, using one or more stack pointers to identify a data position within the operand stack, the stack pointer and the operands. A method for generating parallel transfer of selected data by using a function code from a stack to a logical operation unit that performs processing according to an instruction specified by the function code. 2. A data transfer through a stack processor according to claim 1, wherein the parallel transfer moves 64 bits in parallel, moves 96 bits in parallel, and moves 128 bits in parallel. Method. 3. The method for processing data via a stack processor according to claim 1, wherein the parallel transfer supplies the selected data to a logical operation unit for parallel word processing. 4. A logical operation unit produces a result and transfers the result as one of a single word and a plurality of words onto an operand stack, wherein one or more stack pointers indicate a position in the operand stack for the result. The method for processing data via a stack processor according to claim 1, characterized in that it is specified. 5. The method of processing data through a stack processor according to claim 4, wherein the parallel transfer supplies the selected data to a logical operation unit for parallel word processing. 6. When generating parallel transfer of selected data using a stack pointer and a function code from an operand stack to a logical operation unit, transferring address information of the stack pointer and a decode signal to a selector / multiplexer, The method of processing data through a stack processor of claim 1, wherein the slot select signal received from the selector multiplexer is transferred to the output multiplexer, the output multiplexer selecting specific data from the operand stack. . 7. The method of processing data via a stack processor of claim 1, wherein the stack processor is a Java stack processor. 8. The method of processing data through a stack processor of claim 1, wherein the operand stack is divided into a plurality of banks, each bank being 32 bits wide. 9. The method of processing data via a stack processor of claim 1, wherein identification and generation are controlled by a stack / ALU controller. 10. An operand stack capable of storing data and having banks arranged in a stack processing subsystem; a stack pointer in a stack processing subsystem for locating data within a bank of the operand stack; The logical operation unit connected to the operand stack is provided so that the parallel word transfer of data is performed from the operand stack to the logical operation unit, and the data to be transferred by the parallel word transfer uses the stack pointer and the function code. A stack processing subsystem for data processing, characterized in that the function code specifies a specific instruction to be processed by a logical operation unit. 11. The stack processing subsystem for data processing according to claim 10, wherein the parallel transfer includes 64-bit parallel transfer, 96-bit parallel transfer, and 128-bit parallel transfer. 12. The stack processing subsystem for data processing according to claim 10, wherein a stack pointer in the stack processor identifies a position of processing data in the operand stack. 13. The data processing according to claim 10, wherein the bank selector / multiplexer receives bank address information from the stack pointer and a decode signal from the function code so as to send the slot select signal to the output multiplexer. Stack processing subsystem for. 14. The stack processing subsystem for data processing of claim 13, wherein the output multiplexer selects specific data from the operand stack. 15. The operand stack has a plurality of banks each having a 32-bit word width.
The stack processing subsystem for data processing according to claim 10, wherein the stack processing subsystem is divided into a plurality of banks. 16. The stack processing subsystem for data processing of claim 10, wherein the operand stack is hardware logic. 17. The stack processing subsystem for data processing of claim 10, wherein the stack pointer is hardware logic. 18. The stack processing subsystem for data processing according to claim 10, wherein the logical operation unit is hardware logic. 19. The stack processing subsystem for data processing according to claim 10, further comprising an input multiplexer arranged in the immediate vicinity of the operand stack. 20. The stack processing subsystem for data processing according to claim 14, wherein the output multiplexer is arranged close to an operand stack of the logical operation unit. 21. The stack processing subsystem for data processing of claim 10, wherein the stack pointer is located in the stack / ALU controller. 22. Placing data on an operand stack contained within the stack processor, tracking the data position within the operand stack having a stack pointer located within the stack processor, 128 bits from the operand stack to the logical operation unit. A method of performing data processing by using a stack pointer, which is characterized by transferring data that can be transferred in increments and processing the data in the logical operation unit by an instruction from a function code. 23. A logical operation unit produces a result, transfers the result as one of a single word and a plurality of words to an operand stack, and one or more stack pointers identify the position of the operand stack for the result. The method for performing data processing using a stack pointer according to claim 22, wherein 24. When data is transferred from the operand stack to the logical operation unit, the stack pointer address information and the decode signal are transferred to the selector multiplexer, and the slot select signal received from the selector multiplexer is transferred to the output multiplexer. 23. The method of performing data processing with a stack pointer of claim 22, wherein the output multiplexer selects specific data from the operand stack.