US20040015678A1 - Microprocessor for executing byte compiled Java code - Google Patents
Microprocessor for executing byte compiled Java code Download PDFInfo
- Publication number
- US20040015678A1 US20040015678A1 US10/114,678 US11467802A US2004015678A1 US 20040015678 A1 US20040015678 A1 US 20040015678A1 US 11467802 A US11467802 A US 11467802A US 2004015678 A1 US2004015678 A1 US 2004015678A1
- Authority
- US
- United States
- Prior art keywords
- java
- risc
- module
- microprocessor
- instruction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 claims description 23
- 230000009191 jumping Effects 0.000 claims description 3
- 230000002093 peripheral effect Effects 0.000 claims description 3
- 230000015654 memory Effects 0.000 description 32
- 238000010586 diagram Methods 0.000 description 17
- 230000007246 mechanism Effects 0.000 description 13
- 230000006870 function Effects 0.000 description 7
- 238000012546 transfer Methods 0.000 description 7
- 230000008569 process Effects 0.000 description 6
- 238000012360 testing method Methods 0.000 description 6
- 238000013461 design Methods 0.000 description 5
- 238000006073 displacement reaction Methods 0.000 description 5
- 229910052710 silicon Inorganic materials 0.000 description 5
- 239000010703 silicon Substances 0.000 description 5
- 101100294228 Caenorhabditis elegans nlr-1 gene Proteins 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 230000001343 mnemonic effect Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000014616 translation Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/3017—Runtime instruction translation, e.g. macros
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/30101—Special purpose registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/3012—Organisation of register space, e.g. banked or distributed register file
- G06F9/30134—Register stacks; shift registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/3017—Runtime instruction translation, e.g. macros
- G06F9/30174—Runtime instruction translation, e.g. macros for non-native instruction set, e.g. Javabyte, legacy code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
- G06F9/3877—Concurrent instruction execution, e.g. pipeline, look ahead using a slave processor, e.g. coprocessor
- G06F9/3879—Concurrent instruction execution, e.g. pipeline, look ahead using a slave processor, e.g. coprocessor for non-native instruction execution, e.g. executing a command; for Java instruction set
Definitions
- the invention relates generally to microprocessors, and more specifically to a microprocessor with a Java Virtual machine core architecture.
- Java is an object oriented programming language that has become a de facto standard in network programming. At the present time, Java is also beginning to be utilized in the domain of embedded systems, or systems that contain a microprocessor or a microcontroller. Some of the strong points of the Java environment like its object orientation, automatic garbage collection and run time security features can be used with success in embedded applications. However, its run time environment presents a challenge for system designers because of the resource overhead related to running the Java code in a virtual machine such as an interpreter or a just-in-time compiler.
- the Java binary code, called bytecode is distributed in one or more class files. Bytecodes are the instructions of a hypothetical computer that is specifically designed for the execution of Java programs. Conventional CPUs cannot execute this bytecode and therefore execute it in a software layer called the Java Virtual machine. This machine is an abstract machine specification and no implementation guidelines are given. The Java Virtual Machine Specification is published by Sun Microsystems.
- a Java program there are basically four ways to execute a Java program on a physical computer platform.
- the opcode is computed in a Java compiler 915 and the Java bytecode 925 is sent to an interpreter 930 before being sent to the operating system 950 and being executed by the CPU 960 .
- the interpreter 930 presents a speed penalty of a factor of five compared to executing a program compiled to native code.
- a second method 903 is similar except that instead of using an interpreter, the Java bytecode is dynamically compiled into the binary format 940 for the native platform by a Just In Time (JIT) compiler 935 .
- JIT Just In Time
- This process occurs inside the virtual machine and is not stored after the program has ended.
- the newest Java JIT technique is called HotSpot and uses a principle where bottlenecks are analyzed and recompiled during program execution.
- the JIT compiler will suffer from a memory overhead of a factor of two or three while executing the same application.
- a third method 901 involves the use of cross compilers 910 to compile the Java source code into binary format 920 for the native platform.
- the platform independence is lost and the binary program cannot be executed on multiple platforms.
- a Java operating system 945 and Java processor 970 are used to execute the bytecode directly in silicon.
- Some Java processors have a folding mechanism, which means that several instructions are combined and executed as one. However, most Java processors will execute as an interpreter wherein each opcode is read and then the appropriate action is taken to execute the instruction.
- Java processor the fourth method 904
- Java virtual machines have been developed for embedded processor platforms.
- Most of the software solutions aim for 32 bit processors with some 100K memory size.
- Java hardware processors for executing Java programs on silicon have also been developed.
- These processors which support direct execution of Java instructions, implement 32 bits stack machines.
- Some rely on extensions to the Java binary format in order to offer features like direct addressing and bit manipulation instructions.
- Others do not execute Java binary codes directly, but have a very close architectural match to thereby increase performance of the virtual machine.
- the processors are all targeted for medium to large embedded systems. There are currently no 8 or 16 bit processors available for direct execution of Java byte compiled code, even though the eight bit processor market has been considerably larger than the 32 bit processor market.
- a microprocessor for executing byte compiled Java code in hardware that includes a RISC processor, a Java module for executing a first set of Java instructions in the RISC processor, a RISC module for executing a second set of Java instructions as microcode in the RISC processor, and a data path in the RISC processor, including a register file, shared by both modules.
- the Java module sees the elements in the register file as a circular operand stack and the RISC module sees the plurality of elements as a register file.
- the microprocessor architecture is deduced from the observation that, despite Java's high semantic content instruction set, it shares a majority of the executed instructions with instructions of a generic RISC processor.
- the architecture is intended to provide designers of embedded applications with an easy to integrate, small and cost effective processor solution with a well defined programming model. This results in the processor architecture embracing two programming models, making Java easy to integrate in small to medium size embedded applications.
- FIG. 1 is a Venn diagram showing the overlap between the Java instruction set and a typical RISC instruction set.
- FIG. 2 is a block diagram of the architecture of the microprocessor of the present invention.
- FIG. 3 is a flow chart showing a normal run sequence for the microprocessor of the FIG. 2.
- FIG. 4 is a block diagram of a portion of the register file of the microprocessor of FIG. 2.
- FIG. 5 is a block diagram of the complete register file of the microprocessor of FIG. 2.
- FIG. 6 is a block diagram illustrating the interrupt handling mechanism of the microprocessor of FIG. 2.
- FIG. 7 is a block diagram illustrating the mode transfer mechanism of the microprocessor of FIG. 2.
- FIG. 9 is a block diagram illustrating the instruction format for the RISC portion of the microprocessor of FIG. 2.
- FIG. 20 is a block diagram of the instruction format for the control instructions of the SMILE RISC architecture used in the present invention.
- FIG. 21 is a block diagram of the instruction format of the LL instructions of the SMILE RISC architecture used in the present invention.
- Java Virtual machine instruction consists of an opcode specifying the operation to be performed, followed by zero or more operands embodying values to be performed upon. There are a total of 201 opcodes in the Java Virtual machine instruction set.
- a significant feature of the Java Virtual machine instruction set is that a large number of instructions have a high semantic content. These instructions are difficult to implement in silicon. It is usually not feasible to execute the instructions having a high semantic content in one clock cycle, and the task of breaking them up into several less complex instructions is difficult in respect to resource allocation and timing constraints.
- a large part of the Java instructions are type specific and therefore, there are many instructions which have the same semantic meaning.
- the remaining instructions are divided among the RISC low level bit manipulation instructions 23 and Java's high level object creation and manipulation instructions 21 .
- These observations establish the idea that both a RISC and a Java stack machine require approximately the same hardware resources.
- a Java Virtual machine implementation in silicon needs to support instructions for bit manipulation, direct memory addressing, and trapping of complex opcodes.
- the most frequently executed instructions in both architectures are the load/store instructions. In both architectures, they have the same semantic content. Implemented on silicon, these instructions could share the same hardware resources.
- An arithmetic logic unit (ALU) 42 is connected to the register file 35 and the output of the ALU is supplied to the data bus 40 . This is partly because a large part of the critical path goes through the ALU and partly because this is one of the larger modules in an embedded microprocessor.
- the minimum ALU implementation should perform the operations: ADD, SUB, AND, OR, XOR, MOVE, SET, CLEAR, SHIFT, and ROTATE.
- the outputs of the register file 35 and the program counter 34 are processed through an adder 36 to an address multiplexer 37 .
- the address multiplexer 37 is also connected to the address bus 41 .
- An instruction fetch decoder 39 receives a signal from the data bus 40 and provides an output to the stack control unit 38 .
- the microprocessor first powers up in the RISC mode of operation in order for the initialization code to execute. After the initialization 52 , the microprocessor switches to Java mode 53 and starts executing the Java program 54 . The microprocessor operates in Java mode until one of three events occurs: an interrupt 59 , an unimplemented Java instruction 60 , or a designated Java opcode for switching back to RISC mode 58 . If any of these events occur, the processor will jump to a pre-defined address and switch to RISC mode 55 and in this way handle the event. Upon finishing the RISC routine 56 , the processor will switch back to Java mode 57 and continue to execute the Java code at the point where it left off.
- the Java model is able to execute the Java parts of the program. Such parts may be network capabilities or algorithms which are already implemented in a company's software library, and constitute modules of legacy software for reuse.
- the RISC model aids in execution of the Java code by executing complex instructions as microcode. It also provides a flexible hardware interface which can be used to, for example, control highly specialized peripheral devices like sensors and actuators.
- all Java instructions need to be implemented. However, in an embedded processor targeted for small to medium applications, several of the number formats supported by the Java Virtual machine are excessive. For instance, there are few processors in this segment that offer floating point units. Several of Java's more complex instructions have to be trapped and executed as microcode.
- a key architectural element in the proposed microprocessor architecture is the register file.
- This module has the function of a push-pop stack in Java mode and as a conventional load/store register file in RISC mode. This is also the module which allows the two virtual processors to communicate.
- the RISC part of the architecture 71 sees a register file with N registers, and the RISC architecture interfaces the registers with the data memory through load/store instructions 72 , 73 , 74 .
- the program counter and status register are included in the register file. In order to preserve orthogonality, these special registers are accessible like any other register.
- FIG. 4 shows half of the register file as it is seen from the RISC and Java modes.
- the registers 80 , 81 , 82 are seen by both the Java control unit 61 and the RISC portion of the circuit 71 .
- the remaining N/2 registers are used for, among other things, the program counter, status register, scratch registers and stack control registers.
- the stack is implemented as a circular stack and the stack sizes required are relatively small.
- the stack size is scalable, and the number of stack elements is left as an implementation specific issue.
- a stack overflow/underflow can be copied out in the memory 83 through an overflow/underflow mechanism. Possible stack overflow/underflow mechanisms can also be developed in a case-by-case manner.
- the complete register file 90 is shown.
- the RISC module can read and write from all the registers and there are no hardware limitations on which registers the RISC module can access.
- the verification that the RISC module does not overwrite a special register during program execution is done in the software layer. If the programmer wants to use one of the special registers as a temporary memory, it will have to be stored on the RISC module stack if the value in this register needs to be recovered later during the execution.
- the complete RISC register file 90 includes the Java operand stack 91 which includes a plurality of registers 92 , 93 , 94 , 95 , as was described with reference to FIG. 4.
- the RISC registers 90 also includes a plurality of special registers.
- the special registers include a program counter 106 , a program counter base 105 , a constant pool base address 107 , a local variable base address 104 , a Java stack pointer 103 , a status register 101 , and a RISC stack pointer 102 . Most of these register functions are self-explanatory.
- the program counter base register 105 is used by the Java processor. When a new method is invoked, the Java module's program counter is set to zero.
- the program counter base register stores the address where this method is invoked. On the address bus, this register is added with the program counter in order to fetch instructions from the correct place in the program memory.
- the local variable base address register 104 performs a similar function. It stores the base address for the local variable in a Java method. These registers could of been chosen to reside outside the register file 90 . However, it represents an advantage to be able to have these registers inside the register file since the register can be reached by any RISC instruction, rather than having to implement special instructions to operate on special registers.
- the Java stack pointer 103 keeps track of the location of the top of the Java operand stack, thus keeps track of the particular register of the M registers from which the operand is going to be fetched or to which the operand is going to be written.
- the RISC stack pointer 102 points to a place in memory where the RISC can store variables temporarily if the register file is full.
- the virtual processors communicate through the register file.
- the RISC unit executes, amongst others, complex Java instructions. These small RISC programs have to fetch their operands from the top of the Java operand stack and place the results back to the top of the Java operand stack, and at the same time make sure that the Java stack pointer is incremented or decremented depending on the operation performed. This presents a problem since the RISC instruction format will only handle static registers.
- the problem is solved by setting and clearing two status bits in the status register. Each of the status bits controls whether the source (X) or the destination (Y) operand are to be fetched from the register indicated in the instruction or whether the register number is to be dynamically read from the Java stack pointer register.
- the RISC program which replaces a Java instruction has to set and clear these bits at the appropriate time. By setting the two bits in the register file, the RISC processor can use the content of the top of stack register as an argument for which register to access.
- the Java control 120 and RISC control 122 modules are connected to a multiplexer 124 which produces the control lines 130 to the data path.
- the status register 126 in the register file contains a control bit 128 which is supplied to the Java control module 120 , and the RISC control module 122 .
- the control bit 128 also serves as the control input to the multiplexer 124 .
- the control bit determines which of the control units, Java control unit 120 or RISC control unit 122 , is in operation. Control is transferred at a predefined state in both control modules. Control is therefore transferred synchronously where both machines will be in the same defined state.
- interrupt handling mechanism is shown.
- the processor checks that the implementation specific conditions, like specific flags, are true before jumping to a predefined address and switching to RISC mode. Then, the return address is stored on top of the RISC stack.
- the jump address (0x63) 112 is shown to be stored at the predefined address (0xaf) 111 . At this predefined address, the jump address is read and an appropriate branch instruction to the new address is performed. Execution continues at this new address in RISC mode. To return to normal program execution, the processor executes the RISC instruction “Return from Interrupt” where the return address is popped off the top of the RISC stack.
- the instruction trapping mechanism involves steps similar to the interrupt mechanism.
- the JAVA control module detects this and the return address is stored on the top of the stack. Then, the processor switches to RISC mode and fetches a jump address from a predefined location in the memory. The RISC module then continues execution at the address fetched in the last step. Having the trapping mechanism be similar to the interrupt mechanism achieves maximum flexibility since only the first jump address is predefined in the design. This will enable the software linker to optimally plan the memory usage by only linking the RISC routines for the Java opcodes actually present in the program, thus saving precious memory space.
- the RISC routine should end by popping the program counter off the top of the stack and saving it in the program counter register. This will ensure that the Java program continues at the correct place.
- the microprocessor has a stack overflow/underflow handling mechanism. This mechanism in the Java push-pop stack can be implemented by reusing existing logic for instruction trapping. When an overflow occurs, the processor traps the overflow flag and jumps to a predefined address where it finds a jump vector to the software procedure that will handle the overflow/underflow condition.
- FIG. 8 a typical run-time environment for a system with this processor concept is shown.
- a developer can compile Java source code 141 in an ordinary Java compiler 142 and end up with Java class files 144 .
- the processor accommodates an operating system with a file loader and an automatic memory management system, the rest of this process can occur dynamically and automatically.
- small embedded systems often do not need an operating system and then the rest of this process must be done manually in the sense that a memory image of the program has to be created on an external platform.
- the Java class files 144 have to be parsed through a linker 148 .
- the program run through the linker will verify that the class file doesn't contain any illegal opcodes, modify codes or operands depending on instrumentation solutions, link the application with the specified Java class libraries 145 , link an assembly code to the RISC part 143 , set up a heap area, set up branch and jump addresses, and make a memory map.
- the output from the linker will be a memory image which can be transferred to the ROM or flash memory 151 in the embedded system 152 .
- Much of the purpose of making a Java processor is that the programmer should be able to use the Java programming language as unconstrained as possible. However, in this case, only supported types can be used and only a limited run-time library will be available. These constraints are, however, not limiting for the use of Java's main features.
- the Java Virtual machine specification contains 201 instructions, many of them type specific. The number of instructions hardware implemented, and the number of instructions trapped, depends on the RISC architecture that is used. Other types of RISC architectures will have an effect on the number of instructions hardware implemented and trapped. The following instructions were not hardware implemented in the preferred embodiment of the present invention since these instructions are not considered as important in a small embedded processor: all instructions of type “float”, all instructions of type “double”, and all instructions of type “long”. This eliminates approximately 90 instructions from the 201 possible Java instructions. Of the remaining instructions, 68 instructions are implemented in the Java Virtual machine and 43 instructions are trapped and are executed as RISC routines. The instructions that are trapped and executed as RISC routines are noted below in Table 1.
- Opcode Mnemonics Opcode Mnemonics 18 ldc 104 imul 182 invokevirtual 46 iaload 108 idiv 183 invokespecial 50 aaload 112 irem 184 invokestatic 51 baload 170 tableswitch 185 invokeinterface 52 caload 171 lookupswitch 187 new 53 saload 172 ireturn 188 newarray 79 iastore 173 lreturn 189 anewarray 83 aastore 176 areturn 190 arraylength 84 bastore 177 return 191 athrow 85 castore 178 getstatic 192 checkcast 86 sastore 179 putstatic 193 instanceof 90 dup_x1 180 getfield 194 monitorenter 91 dup_x2 181 putfield 195 monitorexit 92 dup2 197 multianewarray 93 dup2_x1 94 dup2_x2
- SMILE Scalable Microcontroller Library Element
- SMILE is targeted for small embedded systems and has certain scalability qualities.
- the virtual RISC of the present invention implements a modified SMILE instruction set, except that the instructions format was slightly changed in order to accommodate 32 register addressing as is shown in FIG. 9. Additionally, the status registers in the present invention have been modified from the standard SMILE specification registers that are discussed with reference to FIG. 18 below.
- the status registers of the present invention are shown in FIG. 10 and include a read/write register SR1 180 , and a second register SR2 having a read only portion 185 and a write only portion 188 .
- the read/write register SR1 180 includes the Java flag 183 , discussed above with reference to FIG. 6, and also includes the Rx 182 and Ry 181 flags, which will be described below with reference to FIG. 14.
- the remaining bits in the register are the same as in the SMILE specification, which is described below with reference to FIGS. 18 - 21 . Additionally, the range of some instructions were expanded, all registers are defined as type “long”, the register scaling parameters have been changed, and some new instructions were added.
- the new instructions are: return from Java trap (RJ), RISC to Java control transfer (R2J), shift Java alignment left (SJL), and shift Java alignment right (SJR). The semantics of these new instructions are described below with reference to FIGS. 11-16.
- the signals shown in each of FIGS. 11 - 16 are the reset signal 241 , the clock signal 242 , the Java instruction register 243 , the RISC instruction register 244 , the Java flag 245 , the data bus 246 , the program counter 247 , the address bus 248 , the Java Stack pointer 249 and the actual time 250 . Also, the instruction sequences 201 - 206 for each time period are shown.
- FIG. 11 the first ten clock cycles are shown.
- the processor is in RISC mode and initializes by executing the instruction it reads at address 0x0000. It then executes a series of load instructions to initialize the special registers Stack Pointer, Local Variable Base Address, and Program Counter Base Address. The initialization described is valid for a reset routine.
- a JAVA call would include initializing only the Local Variable Base Address and the Program Counter Base Address.
- the Constant Pool Base Address would have to be initialized if a new class was called.
- the processor executes the instruction R2J which is equivalent to setting bit six in the status register.
- the processor switches to Java mode in the next clock cycle.
- the transfer of control is seamless as shown in FIG. 12.
- the Java flag signal 245 is set high at time 105 and that the program counter 247 is set to zero as all Java methods start at zero.
- the address on the address-bus 248 is the sum of the Program Counter and the Program Counter Base Address registers.
- the Top of Stack pointer 249 which points to the register that is currently “Top of Stack”, is decremented as the number is popped off the stack.
- Execution of “istore” at time 215 takes two clock cycles as shown in FIG. 13. Later in the same figure, an “istore”, is executed again at time 245 . This time, the alignment of the instruction in memory forces the opcode and the operand to be read on different clock cycles. The execution of this instruction is thus done in three clock cycles.
- the Java control module reaches the unimplemented instruction “newarray”. This instruction is trapped.
- the trap sequence takes four clock cycles as described above.
- the Java flag goes low.
- the processor now starts executing the instruction newarray as a RISC routine.
- the instruction should initialize an array and return the start address for the array.
- the RISC instructions SJL and SJR are move instructions to handle the alignment of the Java opcodes in the memory.
- the Java stack pointer has a post-increment function.
- the stack pointer is decremented in order for the RISC to access the correct register.
- the RX flag is set in the status register. This means that the RISC reads the Java Stack Pointer register to determine the “Top of Stack”, and uses this as the RX register in the next instructions. This is what happens at time 465 where a constant is loaded into “Top of Stack”. This constant is the return value from the RISC routine returning the address of the newly created array. In this example, the array is static and the return value is therefore loaded as a constant.
- Java stack pointer is incremented again at time 495 before the RISC returns control to the Java module again at time 515 in FIG. 16. The processor then continues to execute in Java mode.
- the SMILE microcontroller must satisfy the following requirements: scalable size, design simplicity, moderate speed and moderate code efficiency. SMILE would typically be part of a larger system including timers, memory and some form of analog interface. The design will follow RISC principles whenever this is practical and relevant.
- the compact instruction set (24 instructions) will have the following features:
- Orthogonality The instruction set will be orthogonal, and there will be no undecoded instructions.
- Parameterization & Scalability as the user may be in a position to modify the core hardware, the design will be parameterized. It will also be possible to scale the design according to the width of the memory, with the smallest width being 4 bits. Functionality will degrade gracefully as the memory width is reduced. Finally, expansion of the instruction set will be allowed through the addition of application specific instructions.
- NRE is a power of 2.
- SMILE versions will be specified as SMILEWSR_WIR_NRE.
- the following parameters are derived from the above: WRF Width of register field in insn 21 ⁇ log 2 (NRE) WCF Width of condn. field in insn.
- WAF Width of address-mode fields 3 NSR Number of short registers 2 (WRD/2) /2 NLR Number of long registers NSR NPA Number of process addresses 2 WLR NTA Number of total addresses 2 2WLR
- the processor switches between processes on interrupt. Each process will see a set of NSR+NLR General Purpose Registers. Register L[NLR ⁇ 1] will be the program counter, PC.
- Status information is held in two registers, SR1 and SR2, as defined by the following diagram.
- the addressing modes used to access this information are shown in FIG. 18 and are described below.
- ST x,y is not an allowed instruction.
- Status bits K and P are affected by all instructions. All instructions may have a further field ⁇ cdn> added to specify a condition (not shown in above table). If this is not specified, then the default condition tests the S bit. This bit is set by all instructions except TB and FB, which sets or clears it depending on the result of the test. Instructions are always executed, and the appropriate status bits set. However, the results are only stored if ⁇ cdn> is true. The y result is always stored in pre-decrement and post-increment instructions.
- the VS instruction is identical to the JS instruction, except that the jump address is not required to follow the instruction.
- this address is fetched from an address table that is internal to the SMILE core, and the index used to retrieve the appropriate address is n ⁇ the VS argument.
- This instruction therefore allows a subroutine jump where the destination of the jump is coded into the instruction itself.
- the displacement follows the instruction in memory.
- ⁇ disp> is a displacement, the same width as y. It is added to y and then the result zero-extended so that, when y is short, the mode can be used to access any element of the first page of memory.
- the arguments Ax and Ay are always treated as having the same width as register x. If the y addressing mode is “register” and y is longer than x, then the least significant part of y is used for the operation.
- the arrangement of the fields in FIG. 19 is with the rx field 501 at the most significant end.
- the format is shown in FIG. 20.
- the fields corresponding to instr, ay and ax of format 1 are occupied with the codes corresponding to ST 555 , “register” 552 and “simple” 553 respectively.
- the remaining three fields must then be divided up into a part that specifies the instruction 551 and a part which specifies the condition 554 .
- the condition part is the four least significant bits of the combined field.
- the remaining instructions are termed “manipulate” instructions (MA instructions).
- the LL instructions is included in this category. Their format is shown in FIG. 21.
- the number of bits available to code the MA instructions 582 will be a function of WIR and NRE, and the minimum number of bits will be 5. This is sufficient to allow the coding of the instructions from TB to RC in the instruction table above. Surplus bits are used to code the instructions LL, where the number of literals that can be coded will depend on the number of surplus bits available.
- 111 MA i.e. the code in the instr field for all the manipulate instructions.
Abstract
A microprocessor architecture for executing byte compiled Java programs directly in hardware. The microprocessor targets the lower end of the embedded systems domain and features two orthogonal programming models, a Java model and a RISC model. The entities share a common data path and operate independently, although not in parallel. The microprocessor includes a combined register file in which the Java module sees the elements in the register file as a circular operand stack and the RISC module sees the elements as a conventional register file. The integrated microprocessor architecture facilitates access to hardware-near instructions and provides powerful interrupt and instruction trapping capabilities.
Description
- The application claims priority from U.S. provisional application No. 60/286,197, filed Apr. 23, 2001.
- The invention relates generally to microprocessors, and more specifically to a microprocessor with a Java Virtual machine core architecture.
- Java is an object oriented programming language that has become a de facto standard in network programming. At the present time, Java is also beginning to be utilized in the domain of embedded systems, or systems that contain a microprocessor or a microcontroller. Some of the strong points of the Java environment like its object orientation, automatic garbage collection and run time security features can be used with success in embedded applications. However, its run time environment presents a challenge for system designers because of the resource overhead related to running the Java code in a virtual machine such as an interpreter or a just-in-time compiler. The Java binary code, called bytecode, is distributed in one or more class files. Bytecodes are the instructions of a hypothetical computer that is specifically designed for the execution of Java programs. Conventional CPUs cannot execute this bytecode and therefore execute it in a software layer called the Java Virtual machine. This machine is an abstract machine specification and no implementation guidelines are given. The Java Virtual Machine Specification is published by Sun Microsystems.
- With reference to FIG. 17, there are basically four ways to execute a Java program on a physical computer platform. In a
first method 902, the opcode is computed in a Javacompiler 915 and the Javabytecode 925 is sent to aninterpreter 930 before being sent to theoperating system 950 and being executed by theCPU 960. However, theinterpreter 930 presents a speed penalty of a factor of five compared to executing a program compiled to native code. - A
second method 903, is similar except that instead of using an interpreter, the Java bytecode is dynamically compiled into thebinary format 940 for the native platform by a Just In Time (JIT)compiler 935. This process occurs inside the virtual machine and is not stored after the program has ended. The newest Java JIT technique is called HotSpot and uses a principle where bottlenecks are analyzed and recompiled during program execution. However, the JIT compiler will suffer from a memory overhead of a factor of two or three while executing the same application. - A
third method 901 involves the use ofcross compilers 910 to compile the Java source code intobinary format 920 for the native platform. However, the platform independence is lost and the binary program cannot be executed on multiple platforms. - In a
fourth method 904, a Javaoperating system 945 and Javaprocessor 970 are used to execute the bytecode directly in silicon. Some Java processors have a folding mechanism, which means that several instructions are combined and executed as one. However, most Java processors will execute as an interpreter wherein each opcode is read and then the appropriate action is taken to execute the instruction. - There is no generally preferred run-time environment. Each of these environments can be used with success for different systems depending on their requirements. However, for embedded systems, the use of a Java processor (the fourth method904) is by far the preferred technical solution if Java is to be implemented in embedded systems. In recent years, several Java virtual machines have been developed for embedded processor platforms. Most of the software solutions aim for 32 bit processors with some 100K memory size. Additionally, some Java hardware processors for executing Java programs on silicon have also been developed. These processors, which support direct execution of Java instructions, implement 32 bits stack machines. Some rely on extensions to the Java binary format in order to offer features like direct addressing and bit manipulation instructions. Others do not execute Java binary codes directly, but have a very close architectural match to thereby increase performance of the virtual machine. The processors are all targeted for medium to large embedded systems. There are currently no 8 or 16 bit processors available for direct execution of Java byte compiled code, even though the eight bit processor market has been considerably larger than the 32 bit processor market.
- It is the object of the present invention to provide a microprocessor for executing Java byte compiled code in hardware.
- It is a further object of the present invention to provide a microprocessor architecture for executing Java that is small and power efficient enough to be a preferred solution in small to medium sized embedded applications.
- The above objects have been achieved by a microprocessor for executing byte compiled Java code in hardware that includes a RISC processor, a Java module for executing a first set of Java instructions in the RISC processor, a RISC module for executing a second set of Java instructions as microcode in the RISC processor, and a data path in the RISC processor, including a register file, shared by both modules. The Java module sees the elements in the register file as a circular operand stack and the RISC module sees the plurality of elements as a register file. The microprocessor architecture is deduced from the observation that, despite Java's high semantic content instruction set, it shares a majority of the executed instructions with instructions of a generic RISC processor. The architecture is intended to provide designers of embedded applications with an easy to integrate, small and cost effective processor solution with a well defined programming model. This results in the processor architecture embracing two programming models, making Java easy to integrate in small to medium size embedded applications.
- FIG. 1 is a Venn diagram showing the overlap between the Java instruction set and a typical RISC instruction set.
- FIG. 2 is a block diagram of the architecture of the microprocessor of the present invention.
- FIG. 3 is a flow chart showing a normal run sequence for the microprocessor of the FIG. 2.
- FIG. 4 is a block diagram of a portion of the register file of the microprocessor of FIG. 2.
- FIG. 5 is a block diagram of the complete register file of the microprocessor of FIG. 2.
- FIG. 6 is a block diagram illustrating the interrupt handling mechanism of the microprocessor of FIG. 2.
- FIG. 7 is a block diagram illustrating the mode transfer mechanism of the microprocessor of FIG. 2.
- FIG. 8 is a block diagram illustrating the run time system in which the microprocessor of FIG. 2 would be implemented.
- FIG. 9 is a block diagram illustrating the instruction format for the RISC portion of the microprocessor of FIG. 2.
- FIG. 10 is a block diagram illustrating the addressing modes for the status registers used in the present invention.
- FIGS.11-16 are timing diagrams illustrating the timing signals during an execution sequence of the microprocessor of FIG. 2.
- FIG. 17 is block diagram illustrating various ways to execute a Java program on a physical computer platform, as are known in the prior art.
- FIG. 18 is a block diagram illustrating the addressing modes for the status registers of the SMILE RISC architecture.
- FIG. 19 is a block diagram of the instruction format for the transfer and arithmetic and logic instructions of the SMILE RISC architecture used in the present invention.
- FIG. 20 is a block diagram of the instruction format for the control instructions of the SMILE RISC architecture used in the present invention.
- FIG. 21 is a block diagram of the instruction format of the LL instructions of the SMILE RISC architecture used in the present invention.
- With reference to FIG. 1, it can be seen that the Java instruction set20 and the typical RISC instruction set 22 overlap. A Java Virtual machine instruction consists of an opcode specifying the operation to be performed, followed by zero or more operands embodying values to be performed upon. There are a total of 201 opcodes in the Java Virtual machine instruction set. A significant feature of the Java Virtual machine instruction set is that a large number of instructions have a high semantic content. These instructions are difficult to implement in silicon. It is usually not feasible to execute the instructions having a high semantic content in one clock cycle, and the task of breaking them up into several less complex instructions is difficult in respect to resource allocation and timing constraints. A large part of the Java instructions are type specific and therefore, there are many instructions which have the same semantic meaning.
- RISC is an abbreviation for “reduced instruction set computer”. The idea behind the RISC architecture is that a simpler instruction set could be executed with a higher clock frequency and more efficient pipe lining, ensuring a higher throughput than in traditional stack machines. The instruction set of a RISC will of course vary from processor to processor but generally it has the following instructions: LOAD, STORE, ADD, SUB, AND, OR, SHIFT, BRANCH. In addition RISC architectures will in general include some form of bit manipulation instructions. Comparing Java's instruction set with a generic RISC instruction set, it can be found that most of the RISC instructions appear in the Java instruction set. The overlap of
common instructions 25 is illustrated in the diagram of FIG. 1. The remaining instructions are divided among the RISC low levelbit manipulation instructions 23 and Java's high level object creation andmanipulation instructions 21. These observations establish the idea that both a RISC and a Java stack machine require approximately the same hardware resources. Additionally, a Java Virtual machine implementation in silicon needs to support instructions for bit manipulation, direct memory addressing, and trapping of complex opcodes. Also, the most frequently executed instructions in both architectures are the load/store instructions. In both architectures, they have the same semantic content. Implemented on silicon, these instructions could share the same hardware resources. These observations on the nature of the two instruction sets leads to the microprocessor architecture of the present invention. - With reference to FIG. 2, the
microprocessor 30 of the present invention includes aJava control unit 31 and aRISC control unit 33 which share the same data path. The twocontrol units processor 30 does not rely on translations or extensions to the Java binary format like other Java processors, but offers two orthogonal programming models. Themicroprocessor 30 is in principle a von-Neuman architecture, but it can easily be expanded to a Harvard architecture with a separate data and instruction bus. The microprocessor includes aregister file 35 having astatus register 32 and aprogram counter 34. The register file is connected to thedata bus 40. An arithmetic logic unit (ALU) 42 is connected to theregister file 35 and the output of the ALU is supplied to thedata bus 40. This is partly because a large part of the critical path goes through the ALU and partly because this is one of the larger modules in an embedded microprocessor. The minimum ALU implementation should perform the operations: ADD, SUB, AND, OR, XOR, MOVE, SET, CLEAR, SHIFT, and ROTATE. The outputs of theregister file 35 and theprogram counter 34 are processed through anadder 36 to anaddress multiplexer 37. Theaddress multiplexer 37 is also connected to theaddress bus 41. An instruction fetchdecoder 39 receives a signal from thedata bus 40 and provides an output to thestack control unit 38. - With reference to FIG. 3, the microprocessor first powers up in the RISC mode of operation in order for the initialization code to execute. After the
initialization 52, the microprocessor switches toJava mode 53 and starts executing theJava program 54. The microprocessor operates in Java mode until one of three events occurs: an interrupt 59, anunimplemented Java instruction 60, or a designated Java opcode for switching back toRISC mode 58. If any of these events occur, the processor will jump to a pre-defined address and switch toRISC mode 55 and in this way handle the event. Upon finishing theRISC routine 56, the processor will switch back toJava mode 57 and continue to execute the Java code at the point where it left off. - Thus, the Java model is able to execute the Java parts of the program. Such parts may be network capabilities or algorithms which are already implemented in a company's software library, and constitute modules of legacy software for reuse. The RISC model aids in execution of the Java code by executing complex instructions as microcode. It also provides a flexible hardware interface which can be used to, for example, control highly specialized peripheral devices like sensors and actuators. In order to be compatible with the Java Virtual machine specification, all Java instructions need to be implemented. However, in an embedded processor targeted for small to medium applications, several of the number formats supported by the Java Virtual machine are excessive. For instance, there are few processors in this segment that offer floating point units. Several of Java's more complex instructions have to be trapped and executed as microcode. Which instructions to trap and which to implement directly into hardware is usually an implementation specific issue decided by the designer. Additionally, which RISC instruction set to use depends on the RISC model chosen, as the present invention can also be used with other types of RISC architectures in addition to the RISC architectural described herein.
- A key architectural element in the proposed microprocessor architecture is the register file. This module has the function of a push-pop stack in Java mode and as a conventional load/store register file in RISC mode. This is also the module which allows the two virtual processors to communicate. With reference to FIG. 4, the RISC part of the
architecture 71 sees a register file with N registers, and the RISC architecture interfaces the registers with the data memory through load/store instructions Java control unit 61 sees the same register file as a push-pop stack with M=N/2 elements. Data is pushed 62 into the register stack and is popped 63 out of the register stack to the Java control unit. FIG. 4 shows half of the register file as it is seen from the RISC and Java modes. Theregisters Java control unit 61 and the RISC portion of thecircuit 71. The remaining N/2 registers are used for, among other things, the program counter, status register, scratch registers and stack control registers. The stack is implemented as a circular stack and the stack sizes required are relatively small. The stack size is scalable, and the number of stack elements is left as an implementation specific issue. A stack overflow/underflow can be copied out in thememory 83 through an overflow/underflow mechanism. Possible stack overflow/underflow mechanisms can also be developed in a case-by-case manner. - With reference to FIG. 5, the
complete register file 90 is shown. The RISC module can read and write from all the registers and there are no hardware limitations on which registers the RISC module can access. The verification that the RISC module does not overwrite a special register during program execution is done in the software layer. If the programmer wants to use one of the special registers as a temporary memory, it will have to be stored on the RISC module stack if the value in this register needs to be recovered later during the execution. As shown in FIG. 5, the completeRISC register file 90 includes theJava operand stack 91 which includes a plurality ofregisters program counter 106, aprogram counter base 105, a constantpool base address 107, a localvariable base address 104, aJava stack pointer 103, astatus register 101, and aRISC stack pointer 102. Most of these register functions are self-explanatory. The programcounter base register 105 is used by the Java processor. When a new method is invoked, the Java module's program counter is set to zero. The program counter base register stores the address where this method is invoked. On the address bus, this register is added with the program counter in order to fetch instructions from the correct place in the program memory. The local variablebase address register 104 performs a similar function. It stores the base address for the local variable in a Java method. These registers could of been chosen to reside outside theregister file 90. However, it represents an advantage to be able to have these registers inside the register file since the register can be reached by any RISC instruction, rather than having to implement special instructions to operate on special registers. TheJava stack pointer 103 keeps track of the location of the top of the Java operand stack, thus keeps track of the particular register of the M registers from which the operand is going to be fetched or to which the operand is going to be written. TheRISC stack pointer 102 points to a place in memory where the RISC can store variables temporarily if the register file is full. - The virtual processors communicate through the register file. The RISC unit executes, amongst others, complex Java instructions. These small RISC programs have to fetch their operands from the top of the Java operand stack and place the results back to the top of the Java operand stack, and at the same time make sure that the Java stack pointer is incremented or decremented depending on the operation performed. This presents a problem since the RISC instruction format will only handle static registers. The problem is solved by setting and clearing two status bits in the status register. Each of the status bits controls whether the source (X) or the destination (Y) operand are to be fetched from the register indicated in the instruction or whether the register number is to be dynamically read from the Java stack pointer register. The RISC program which replaces a Java instruction has to set and clear these bits at the appropriate time. By setting the two bits in the register file, the RISC processor can use the content of the top of stack register as an argument for which register to access.
- With reference to FIG. 7, the implementation of the mode transfer mechanism of the microprocessor is shown. The
Java control 120 andRISC control 122 modules are connected to amultiplexer 124 which produces thecontrol lines 130 to the data path. Thestatus register 126 in the register file contains acontrol bit 128 which is supplied to theJava control module 120, and theRISC control module 122. Thecontrol bit 128 also serves as the control input to themultiplexer 124. The control bit determines which of the control units,Java control unit 120 orRISC control unit 122, is in operation. Control is transferred at a predefined state in both control modules. Control is therefore transferred synchronously where both machines will be in the same defined state. - The Java Virtual machine specification does not describe the concept of interrupts. Therefore interrupts are handled by default by the RISC module. With reference to FIG. 6, the interrupt handling mechanism is shown. In general, when an interrupt occurs, the processor checks that the implementation specific conditions, like specific flags, are true before jumping to a predefined address and switching to RISC mode. Then, the return address is stored on top of the RISC stack. In FIG. 6, the jump address (0x63)112 is shown to be stored at the predefined address (0xaf) 111. At this predefined address, the jump address is read and an appropriate branch instruction to the new address is performed. Execution continues at this new address in RISC mode. To return to normal program execution, the processor executes the RISC instruction “Return from Interrupt” where the return address is popped off the top of the RISC stack.
- The instruction trapping mechanism involves steps similar to the interrupt mechanism. When an unimplemented instruction occurs, the JAVA control module detects this and the return address is stored on the top of the stack. Then, the processor switches to RISC mode and fetches a jump address from a predefined location in the memory. The RISC module then continues execution at the address fetched in the last step. Having the trapping mechanism be similar to the interrupt mechanism achieves maximum flexibility since only the first jump address is predefined in the design. This will enable the software linker to optimally plan the memory usage by only linking the RISC routines for the Java opcodes actually present in the program, thus saving precious memory space. The RISC routine should end by popping the program counter off the top of the stack and saving it in the program counter register. This will ensure that the Java program continues at the correct place. Additionally, the microprocessor has a stack overflow/underflow handling mechanism. This mechanism in the Java push-pop stack can be implemented by reusing existing logic for instruction trapping. When an overflow occurs, the processor traps the overflow flag and jumps to a predefined address where it finds a jump vector to the software procedure that will handle the overflow/underflow condition.
- With reference to FIG. 8, a typical run-time environment for a system with this processor concept is shown. A developer can compile
Java source code 141 in anordinary Java compiler 142 and end up with Java class files 144. If the processor accommodates an operating system with a file loader and an automatic memory management system, the rest of this process can occur dynamically and automatically. However, small embedded systems often do not need an operating system and then the rest of this process must be done manually in the sense that a memory image of the program has to be created on an external platform. The Java class files 144 have to be parsed through alinker 148. The program run through the linker will verify that the class file doesn't contain any illegal opcodes, modify codes or operands depending on instrumentation solutions, link the application with the specifiedJava class libraries 145, link an assembly code to theRISC part 143, set up a heap area, set up branch and jump addresses, and make a memory map. The output from the linker will be a memory image which can be transferred to the ROM orflash memory 151 in the embeddedsystem 152. Much of the purpose of making a Java processor is that the programmer should be able to use the Java programming language as unconstrained as possible. However, in this case, only supported types can be used and only a limited run-time library will be available. These constraints are, however, not limiting for the use of Java's main features. - The Java Virtual machine specification contains201 instructions, many of them type specific. The number of instructions hardware implemented, and the number of instructions trapped, depends on the RISC architecture that is used. Other types of RISC architectures will have an effect on the number of instructions hardware implemented and trapped. The following instructions were not hardware implemented in the preferred embodiment of the present invention since these instructions are not considered as important in a small embedded processor: all instructions of type “float”, all instructions of type “double”, and all instructions of type “long”. This eliminates approximately 90 instructions from the 201 possible Java instructions. Of the remaining instructions, 68 instructions are implemented in the Java Virtual machine and 43 instructions are trapped and are executed as RISC routines. The instructions that are trapped and executed as RISC routines are noted below in Table 1.
TABLE 1 Opcode Mnemonics Opcode Mnemonics Opcode Mnemonics 18 ldc 104 imul 182 invokevirtual 46 iaload 108 idiv 183 invokespecial 50 aaload 112 irem 184 invokestatic 51 baload 170 tableswitch 185 invokeinterface 52 caload 171 lookupswitch 187 new 53 saload 172 ireturn 188 newarray 79 iastore 173 lreturn 189 anewarray 83 aastore 176 areturn 190 arraylength 84 bastore 177 return 191 athrow 85 castore 178 getstatic 192 checkcast 86 sastore 179 putstatic 193 instanceof 90 dup_x1 180 getfield 194 monitorenter 91 dup_x2 181 putfield 195 monitorexit 92 dup2 197 multianewarray 93 dup2_x1 94 dup2_x2 - With these implementation choices, approximately 70% of the executed instructions will be executed in the processor directly, while approximately 30% will be trapped and executed as RISC programs. These percentages are derived from dynamic measurements.
- For the RISC architecture, the SMILE RISC architecture was chosen. SMILE is an abbreviation for “Scalable Microcontroller Library Element”, and was developed by Andrew K. Betts at University College London and is described in several publications, including:
- A. K. Betts, I. Bolsens, E. Sicard, M. Renaudin, and A. Johnstone, SMILE, a scalable microcontroller library element, In Proceedings of Euromicro, 1993;
- A. K. Betts, I. Bolsens, E. Sicard, M. Renaudin, and A. Johnstone, SMILE, a scalable microcontroller library element, Microprocessors and Microprogramming, 39:259-262, 1994; and
- A. K. Betts, SMILE, scalable microcontroller library element, functional specification, V.6. Technical report, University College London, 1993.
- The essential details of the SMILE specification are described below at the end of this section. SMILE is targeted for small embedded systems and has certain scalability qualities. The virtual RISC of the present invention implements a modified SMILE instruction set, except that the instructions format was slightly changed in order to accommodate 32 register addressing as is shown in FIG. 9. Additionally, the status registers in the present invention have been modified from the standard SMILE specification registers that are discussed with reference to FIG. 18 below. The status registers of the present invention are shown in FIG. 10 and include a read/write
register SR1 180, and a second register SR2 having a readonly portion 185 and a writeonly portion 188. The read/writeregister SR1 180 includes theJava flag 183, discussed above with reference to FIG. 6, and also includes theRx 182 andRy 181 flags, which will be described below with reference to FIG. 14. The remaining bits in the register are the same as in the SMILE specification, which is described below with reference to FIGS. 18-21. Additionally, the range of some instructions were expanded, all registers are defined as type “long”, the register scaling parameters have been changed, and some new instructions were added. The new instructions are: return from Java trap (RJ), RISC to Java control transfer (R2J), shift Java alignment left (SJL), and shift Java alignment right (SJR). The semantics of these new instructions are described below with reference to FIGS. 11-16. - The signals shown in each of FIGS.11-16 are the
reset signal 241, theclock signal 242, theJava instruction register 243, theRISC instruction register 244, theJava flag 245, thedata bus 246, theprogram counter 247, theaddress bus 248, theJava Stack pointer 249 and theactual time 250. Also, the instruction sequences 201-206 for each time period are shown. - In FIG. 11, the first ten clock cycles are shown. After the
reset signal 241 goes inactive, the processor is in RISC mode and initializes by executing the instruction it reads at address 0x0000. It then executes a series of load instructions to initialize the special registers Stack Pointer, Local Variable Base Address, and Program Counter Base Address. The initialization described is valid for a reset routine. A JAVA call would include initializing only the Local Variable Base Address and the Program Counter Base Address. In addition, the Constant Pool Base Address would have to be initialized if a new class was called. Attime 95, the processor executes the instruction R2J which is equivalent to setting bit six in the status register. - After the instruction R2J is executed, the processor switches to Java mode in the next clock cycle. The transfer of control is seamless as shown in FIG. 12. Note that the
Java flag signal 245 is set high attime 105 and that theprogram counter 247 is set to zero as all Java methods start at zero. The address on the address-bus 248 is the sum of the Program Counter and the Program Counter Base Address registers. - As shown in FIG. 13, at
time 215, the Java instruction “istore <index>” is executed (“36” in Java instruction register 243). This instruction pops a variable of “Top of Stack” and stores it into a local variable at address “<index>”. It can be seen that the number “0” (see databus 246) is stored into address “184” on theaddress bus 248. The address is calculated from LV base address plus PC base address plus the operand <index> which belonged to the instruction. Here <index> was 0x4 thus the address is 0x69+0x4B+0x04=0xB8=184. In addition, it can be observed that the Top ofStack pointer 249, which points to the register that is currently “Top of Stack”, is decremented as the number is popped off the stack. - Execution of “istore” at
time 215 takes two clock cycles as shown in FIG. 13. Later in the same figure, an “istore”, is executed again attime 245. This time, the alignment of the instruction in memory forces the opcode and the operand to be read on different clock cycles. The execution of this instruction is thus done in three clock cycles. - At
time 315 in FIG. 14, the Java control module reaches the unimplemented instruction “newarray”. This instruction is trapped. The trap sequence takes four clock cycles as described above. At the 350, the end of the top sequence, the Java flag goes low. The processor now starts executing the instruction newarray as a RISC routine. The instruction should initialize an array and return the start address for the array. The RISC instructions SJL and SJR are move instructions to handle the alignment of the Java opcodes in the memory. - With reference to FIG. 15, the Java stack pointer has a post-increment function. At
time 435 the stack pointer is decremented in order for the RISC to access the correct register. Next, attime 455 in FIG. 14, the RX flag is set in the status register. This means that the RISC reads the Java Stack Pointer register to determine the “Top of Stack”, and uses this as the RX register in the next instructions. This is what happens attime 465 where a constant is loaded into “Top of Stack”. This constant is the return value from the RISC routine returning the address of the newly created array. In this example, the array is static and the return value is therefore loaded as a constant. - Finally, the Java stack pointer is incremented again at
time 495 before the RISC returns control to the Java module again attime 515 in FIG. 16. The processor then continues to execute in Java mode. - Smile Specification
- As discussed above, the SMILE RISC specification was chosen in the implementation of the present invention. The specification of the SMILE implementation used in the present invention is described herein.
- The SMILE microcontroller must satisfy the following requirements: scalable size, design simplicity, moderate speed and moderate code efficiency. SMILE would typically be part of a larger system including timers, memory and some form of analog interface. The design will follow RISC principles whenever this is practical and relevant. The compact instruction set (24 instructions) will have the following features:
- Uniformity: Every type of operation will be applicable to all processor registers and all combinations of processor registers in the same way (with the exception of some operations on the status register), and all instructions will be conditioned.
- Completeness: The instruction set will be complete with respect to the application area of embedded control.
- Orthogonality: The instruction set will be orthogonal, and there will be no undecoded instructions.
- Parameterization & Scalability: as the user may be in a position to modify the core hardware, the design will be parameterized. It will also be possible to scale the design according to the width of the memory, with the smallest width being 4 bits. Functionality will degrade gracefully as the memory width is reduced. Finally, expansion of the instruction set will be allowed through the addition of application specific instructions.
- The following three parameters will be specified in order to characterize a particular version of SMILE:
WSR Width of short register in bits WSR ≧4 WIR Width of instruction register WIR ≧12 NRE Number of registers NRE ≧8 - The following restrictions apply to the choice of the above parameters. NRE is a power of 2.
- 6≦WIR−2log2(NRE)≦10
- SMILE versions will be specified as SMILEWSR_WIR_NRE. The following parameters are derived from the above:
WRF Width of register field in insn 21 · log2 (NRE) WCF Width of condn. field in insn. WIR - WRF - 6 NIS Number of segs in insn reg (WIR + WSR-1)/WSR (integer truncated) WLR Width of long registers 2 · WSR WIF Width of instruction field =3 WAF Width of address-mode fields =3 NSR Number of short registers 2(WRD/2)/2 NLR Number of long registers NSR NPA Number of process addresses 2WLR NTA Number of total addresses 22WLR - The processor switches between processes on interrupt. Each process will see a set of NSR+NLR General Purpose Registers. Register L[NLR−1] will be the program counter, PC.
- Register L[0] will be the stack pointer, SP. Register S[NSR−1] will be the Interrupt Control and Status Register, SR. Registers designated “local” are stacked on interrupt. The local registers are to be the Program Counter, PC (L[NLR−1]), the Status Register, SR ((S[NSR−1]), and the Memory Configuration Register, MCR. All other registers will be designated “global”. When short registers are combined in an operation with long registers, or they are used as an address, they are zero-extended. This allows the short registers to be used to point to the first page (2WSR locations) of data memory.
- Status information is held in two registers, SR1 and SR2, as defined by the following diagram. The addressing modes used to access this information are shown in FIG. 18 and are described below.
- With reference to FIG. 18, the status bits are as follows:
SR1 (read/write), 411: U User bit-no dedicated function N Negative flag V Overflow flag Z Zero flag C Carry flag SR2 (read only), 421: M =Z + C bar (convenient access to condition “lower or same”) I =Z + L (convenient access to condition “less or equal”) L =N{circumflex over ( )}V (convenient access to condition “less”) E interrupts enabled when this is set SR2 (write only), 422: S holds results of TB & FB instructions set to 1 by other instructions K set to 1 unless instruction explicitly clears P set to 1 unless instruction explicitly clears E as above - For this version of the specification, data and instruction memories will be identical. Memory accesses that use the program counter as a pointer will read instruction memory, while all others will read or write data memory (nb, immediate constants are therefore in instruction memory). Accesses to instruction memory are read-only. Memory will be accessed as shorts or longs, depending on the operation. The high and low parts of longs will be ordered according to the little endian convention.
- The instruction set is noted in Table 2 below:
TABLE 2 Operation Flags Transfers LD Ax, Ay load Ax<=Ay sz ST Ax, Ay store Ay<=Ax sz Arithmetic and Logical AD Ax, Ay add Ax<=Ax + Ay + C · Kbar SCZNV SU Ax, Ay substract Ax<=Ax − Ay − Cbar · Kbar SCZNV AN Ax, Ay and Ax · Ay SZN OR Ax, Ay or Ax | Ay SZN EO Ax, Ay exclusive or Ax {circumflex over ( )} Ay SZN Manipulation and Test TB Ax,n test bit n(0. . .3) for True S<=Ax · 2n sz FB Ax, n test bit n(0. . .3) for False S<=! (Ax · 2n) sz SB Ax, n set bit n(0. . .3) Ax<=Ax + 2n sz CB Ax, n clear bit n(0. . .3) Ax<=Ax · (2n)bar sz SL Ax, n shift left n(1, 2, 4) Ax<=Ax << n(shifting in 0) SCZ SR Ax, n shift right n(1, 2, 4) Ax<=Ax >> n(shifting in 0) SCZ SA Ax, n shift arith. n(1, 2) Ax<=Ax >> n SCZ (shifting in ms_bit) RL Ax, n rotate left n(1, 2, 4) Ax<=Ax << n(shifting in msb) SCZ RR Ax, n rotate right N(1, 2, 4) Ax<=Ax >> n(shifting in lsb) SCZ RC Ax, d rotate carry (d = L/R) Ax rotated 1 bit L/R SCZ through carry Control BR <offset> branch PC <= PC + (signed) offset s JS <laddr> jump subroutine stack PS, PC <=<laddr> s JI <daddr> jump with int. see text s RI return from int. see text s Version Specific LL Ax, n load literal n Ax <=n sz VS n vectored subroutine see text s FN n, [<arg>] function n not specified s nb. abbreviations: <offset> signed offset, length WSR <laddr> absolute address, length WLR <dladdr> absolute address, length 2 · WLR (for PC + MCR)<constant> immediate constant value |<arg>| unspecified optional parameter to pass to function - The following are attributes of the instruction set shown in Table 2. ST x,y is not an allowed instruction. Status bits K and P are affected by all instructions. All instructions may have a further field <cdn> added to specify a condition (not shown in above table). If this is not specified, then the default condition tests the S bit. This bit is set by all instructions except TB and FB, which sets or clears it depending on the result of the test. Instructions are always executed, and the appropriate status bits set. However, the results are only stored if<cdn> is true. The y result is always stored in pre-decrement and post-increment instructions. The VS instruction is identical to the JS instruction, except that the jump address is not required to follow the instruction. Instead, this address is fetched from an address table that is internal to the SMILE core, and the index used to retrieve the appropriate address is n−the VS argument. This instruction therefore allows a subroutine jump where the destination of the jump is coded into the instruction itself.
- The addressing modes for the Ax operand are defined as follows:
addressing mode <operand> effective address for Ax simple x x indirect (xid) (x) M[x] - The addressing modes for the Ay operand are defined as follows:
addressing mode <operand> effective address for Ay register y y pre-decr −(y) M[y − 1], y decremented post-incr (y)+ M[y], y incremented displacement <disp> (y) M[<disp> + y] immediate <constant> M[PC] - For displacement mode, the displacement follows the instruction in memory. For post-incr and pre-decr modes, the increment/decrement value=1 if the register in the x field is short, else=2. <disp> is a displacement, the same width as y. It is added to y and then the result zero-extended so that, when y is short, the mode can be used to access any element of the first page of memory. The arguments Ax and Ay are always treated as having the same width as register x. If the y addressing mode is “register” and y is longer than x, then the least significant part of y is used for the operation. If the y addressing mode is “register” and y is shorter than x, then y is zero-extended for the operation. The status register address has a special logical interpretation:
Instruction argument Effective argument Ax = SR Ay = SR1 Ax = (SR) Ay = SR2 Ay = SR Ay = SR1 Ay = −(SR) Ay = −(SR) Ay = (SR)+ Ay = (SR)+ Ay = <disp>(SR) Ay = M[<disp>] - S.K and Y are set to one every instruction, unless otherwise specified.
- Table 3 defines the status calculations, where: Ax_result denotes the result of the calculation for Ax which, in fact, will only be stored if the condition corresponding to the operation is met. Ay_result denotes the result of the calculation of the effective address for the y field in pre-decrement, post-increment and displacement addressing modes.
TABLE 3 Transfers LD Ax, Ay Z = if (Ax_result == 0 ? 1:0) ST Ax, Ay Z = if (Ay_result == 0 ? 1:0) Arithmetic and Logical AD Ax,Ay C = if (carry out of Ax_result ? 1:0) Z = if (Ax_result == 0 ? 1:0) N = msbit of Ax_result SU Ax, Ay C = if (borrow from Ax_result ? 0:1) Z = if (Ax_result == 0 ? 1:0) V = if (overflow of Ax_result ? 1:0) N = msbit of Ax_result AN Ax, Ay Z = if (Ax_result == 0 ? 1:0) N = msbit of Ax_result OR Ax, Ay Z = if (Ax_result == 0 ? 1:0) N = msbit of Ax-result EO Ax, Ay Z = if (Ax_result == 0 ? 1:0) N = msbit of Ax_result Manipulation and Test TB Ax,n S = Ax·2n Z = Ax·2n FB Ax, n S = ! (Ax·2n) Z = ! (Ax·2n) SB Ax, n Z = if (Ax_result == 0 ? 1:0) CB Ax, n Z = if (Ax_result == 0 ? 1:0) SL Ax, n C = if (carry out of Ax_result ? 1:0) Z = if (Ax_result == 0 ? 1:0) SR Ax, n C = if (carry out of Ax_result ? 1:0) Z = if (Ax_result == 0 ? 1:0) SA Ax, n C = if (carry out of Ax_result ? 1:0) Z = if (Ax_result == 0 ? 1:0) RL Ax, n C = if (carry out of Ax_result ? 1:0) Z = if (Ax_result == 0 ? 1:0) RR Ax, n C = if (carry out of Ax_result ? 1:0) Z = if (Ax_result == 0 ? 1:0) RC Ax, d C = if (carry out of Ax_result ? 1:0) Z = if (Ax_result == 0 ? 1:0) Version Specific LL Ax, n Z = if (Ax_result == 0 ? 1:0) - The code for an immediate mode instruction, IN Ax, <constant>, is identical to the code for IN Ax, (PC)+, followed by the <constant> value, where the latter value has the size of the x register. In this context, IN stands for LD|ST|AD|SU|AN|OR|EO. The instruction format for LD, ST, AD, SU, AN, OR, EO is shown in FIG. 18, where instr506 is the instruction field, ax (formerly id) 504 is the addressing mode field for x,
ay 503 is the addressing mode field for y, cdn 505 is the condition field and rx, ry 501, 502 are the register fields. The arrangement of the fields in FIG. 19 is with therx field 501 at the most significant end. For BR, JS, JI, RI, VS and FN the format is shown in FIG. 20. In this case, the fields corresponding to instr, ay and ax offormat 1 are occupied with the codes corresponding toST 555, “register” 552 and “simple” 553 respectively. The remaining three fields must then be divided up into a part that specifies theinstruction 551 and a part which specifies thecondition 554. The condition part is the four least significant bits of the combined field. The remaining instructions are termed “manipulate” instructions (MA instructions). The LL instructions is included in this category. Their format is shown in FIG. 21. The number of bits available to code theMA instructions 582 will be a function of WIR and NRE, and the minimum number of bits will be 5. This is sufficient to allow the coding of the instructions from TB to RC in the instruction table above. Surplus bits are used to code the instructions LL, where the number of literals that can be coded will depend on the number of surplus bits available. - The fields of the SMILE instruction are coded as follows:
- instr:
- 000 LD
- 001 ST
- 010 AD
- 011 SU
- 100 AN
- 101 OR
- 110 EO
- 111 MA (i.e. the code in the instr field for all the manipulate instructions.)
- ax:
- 0 Ax=x
- 1 Ax=(x)
- ay:
- 00 Ay=y
- 01 Ay=−(y)
- 10 Ay=(y)+
- 11 Ay=#(y)
- The remaining fields do not have fixed width and so the following specifications must be interpreted according to the number of bits available in a particular application.
- rx and ry:
- 000...000 S[0]
- 000...001 S[1]
- etc...
- 011...111 S[NSR−1] (=SP)
- 100...000 L[0] (=SP)
- 100...001 L[1]
- etc...
- 111...111 L[NLR−1] (=PC)
- cdn:
- 000 S if_set(“always”)
- 0001 Sbar if_not_set(“never”)
- 0010 C if_carry
- 0011 Zbar if_not_zero
- 0100 Cbar if_not_carry
- 0101 Z if_zero
- 0110 N if_negative
- 0111 V if_overflow
- 1000 Nbar if_not_negative
- 1001 Vbar if_not_overflow
- 1010 L if_less(<0)
- 1011 Lbar if_ge(≧0)
- 1100 1 if_le(≦0)
- 1101 M if_ls (lower/same)
- 1110 Ibar if_gt (>0)
- 1111 Mbar if_hi (higher)
- control_instr:
- 00..000 BR
- 00..001 JS
- 00..010 JI
- 00..011 RI
- 00..100
VS 4 - 00..101
VS 5 - etc..
- 11..111 VS 2n−1 (n==width of bit field for control_instr)
- If application-specific instructions are implemented, then they take the codes of the highest numbered VS codes.
- ma_instr:
- 00..000000
LL 0 - 00..000001
LL 1 - 00..000010
LL 2 - etc..
- 11..011111
LL 2n−132 (n==width of bit field for ma_instr) - 11..100000
TB 0 - 11..100001
TB 1 - 11..100010
TB 2 - 11..100011
TB 3 - 11..100100
FB 0 - 11..100101
FB 1 - 11..100110
FB 2 - 11..100111
FB 3 - 11..101000
SB 0 - 11..101001
SB 1 - 11..101010
SB 2 - 11..101011
SB 3 - 11..101100
CB 0 - 11..101101
CB 1 - 11..101110
CB 2 - 11..101111
CB 3 - 11..110000
SL 1 - 11..110001
SR 1 - 11..10010
RL 1 - 11..110011
RR 1 - 11..110100
SL 2 - 11..110101
SR 2 - 11..110110
RL 2 - 11..110111
RR 2 - 11..111000
SL 4 - 11..111001
SR 4 - 11..111010
RL 4 - 11..111011
RR 4 - 11..111100
SA 1 - 11..111101
SA 2 - 11..111110 RC L
- 11..111111 RC R
Claims (20)
1. A microprocessor for executing byte compiled Java code in hardware comprising:
a RISC processor;
a Java module to execute a first set of Java instructions in the RISC processor;
a RISC module to execute a second set of Java instructions as microcode in the RISC processor, said RISC module including means for handling interrupts and a flexible hardware interface to control highly specialized peripheral devices; and
a datapath in the RISC processor shared by both modules, said datapath including a register file shared by both modules, said register file having a plurality of elements shared by the Java module and the RISC module, the Java module seeing a first portion of the plurality of elements as a circular Java operand stack and a remaining portion of the plurality of elements as storage registers, the RISC module seeing the plurality of elements as a register file.
2. The microprocessor of claim 1 wherein the register file includes a control bit for tracking which module is in operation.
3. The microprocessor of claim 1 wherein the register file includes a program counter containing the address of an instruction to be executed.
4. The microprocessor of claim 1 wherein the register file includes a program counter base register for storing the address of a new method to be invoked.
5. The microprocessor of claim 1 wherein the register file includes a local variable base address to store base address information for local variables in a Java method.
6. The microprocessor of claim 1 wherein the register file includes a Java stack pointer to track a location of the top of the Java operand stack.
7. The microprocessor of claim 1 wherein the register file includes a RISC stack pointer to point to a location where the RISC can temporarily store variables if the register file is full.
8. The microprocessor of claim 1 wherein the register file includes a status register having a pair of status bits that inform the RISC module to use a value of the top of the JAVA operand stack as a register operand when executing a Java instruction, each of the pair of status bits controlling an source or a destination operand.
9. The microprocessor of claim 8 wherein when the status bits are set, the RISC module disregards the source or destination operand and uses the contents of a predefined register as the source or destination operand.
10. The microprocessor of claim 8 wherein the status bits are set and cleared by a RISC program that replaces the Java instruction.
11. The microprocessor of claim 1 wherein the RISC processor has a SMILE RISC architecture.
12. The microprocessor of claim 1 wherein a control bit is located in a status register that is located outside of the register file.
13. A microprocessor for executing byte compiled Java code in hardware comprising:
a RISC processor;
a Java module to execute a first set of Java instructions in the RISC processor;
a RISC module to execute a second set of Java instructions as microcode in the RISC processor, the second set of instructions being more complex than the first set of instructions, said RISC module including means for handling interrupts and a flexible hardware interface to control highly specialized peripheral devices; and
a datapath shared by both modules, said datapath including a register file shared by both modules, said register file including:
i) a plurality of elements shared by the Java module and the RISC module, the Java module seeing half of these elements as a circular Java operand stack and the other half as storage registers, the RISC module seeing the plurality of elements as a register file;
ii) a control bit tracking which module is in operation;
iii) a program counter containing the address of an instruction to be executed;
iv) a program counter base register storing the address of a new method to be invoked;
v) a local variable base address to store base address information for local variables in a Java method;
vi) a constant pool address to store the base address information for the constant pool in a Java class;
vii) a Java stack pointer to track where the top of the JAVA operand stack is; and
viii) a RISC stack pointer to point where the RISC can temporarily store variables if the register file is full.
14. The microprocessor of claim 13 wherein the register file includes a pair of status bits that inform the RISC module to use a value of the top of the JAVA operand stack as a register operand when executing a Java instruction, each of the pair of status bits controlling a source or a destination operand.
15. The microprocessor of claim 14 wherein when the status bits are set, the RISC module disregards the source or destination operand and uses the contents of a predefined register as the source or destination operand.
16. The microprocessor of claim 14 wherein the status bits are set and cleared by a RISC program that replaces the Java instruction.
17. The microprocessor of claim 13 further comprising means for trapping a stack overflow flag when an overflow occurs.
18. The microprocessor of claim 17 wherein the means for trapping the stack overflow flag includes means for storing a return address on the top of the RISC stack, means for jumping to a predefined address, means for reading a new branch address and means for switching to a RISC mode and means for branching to the start of a RISC routine.
19. A method of executing Java code in a RISC processor, said method comprising:
executing a first set of Java instructions in the processor with a Java module,
executing a second set of Java instructions in the RISC processor with a RISC module, the second set being more complex than the first set;
interrupting the processor when an instruction too complex for execution by the Java module appears;
executing the complex instruction separately from other instructions in the RISC module; and
returning to the Java module when the RISC module has finished executing the complex instruction.
20. The method of claim 19 wherein the interrupting the processor includes:
confirming that a set of implementation specific conditions require the processor to be interrupted;
storing a return address on the top of a stack in the RISC module;
jumping to a predefined address and reading a new branch address;
executing a branch instruction to the new branch address in the RISC module; and
executing a return instruction to return to program execution using the Java module.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/114,678 US20040015678A1 (en) | 2001-04-23 | 2002-04-01 | Microprocessor for executing byte compiled Java code |
US11/619,923 US7917732B2 (en) | 2001-04-23 | 2007-01-04 | Microprocessor for executing byte compiled JAVA code |
US13/030,984 US8166280B2 (en) | 2001-04-23 | 2011-02-18 | Microprocessor for executing byte compiled JAVA code |
US13/453,075 US8533433B2 (en) | 2001-04-23 | 2012-04-23 | Microprocessor for executing byte compiled java code |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US28619701P | 2001-04-23 | 2001-04-23 | |
US10/114,678 US20040015678A1 (en) | 2001-04-23 | 2002-04-01 | Microprocessor for executing byte compiled Java code |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/619,923 Continuation US7917732B2 (en) | 2001-04-23 | 2007-01-04 | Microprocessor for executing byte compiled JAVA code |
Publications (1)
Publication Number | Publication Date |
---|---|
US20040015678A1 true US20040015678A1 (en) | 2004-01-22 |
Family
ID=23097513
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/114,678 Abandoned US20040015678A1 (en) | 2001-04-23 | 2002-04-01 | Microprocessor for executing byte compiled Java code |
US11/619,923 Expired - Fee Related US7917732B2 (en) | 2001-04-23 | 2007-01-04 | Microprocessor for executing byte compiled JAVA code |
US13/030,984 Expired - Lifetime US8166280B2 (en) | 2001-04-23 | 2011-02-18 | Microprocessor for executing byte compiled JAVA code |
US13/453,075 Expired - Lifetime US8533433B2 (en) | 2001-04-23 | 2012-04-23 | Microprocessor for executing byte compiled java code |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/619,923 Expired - Fee Related US7917732B2 (en) | 2001-04-23 | 2007-01-04 | Microprocessor for executing byte compiled JAVA code |
US13/030,984 Expired - Lifetime US8166280B2 (en) | 2001-04-23 | 2011-02-18 | Microprocessor for executing byte compiled JAVA code |
US13/453,075 Expired - Lifetime US8533433B2 (en) | 2001-04-23 | 2012-04-23 | Microprocessor for executing byte compiled java code |
Country Status (9)
Country | Link |
---|---|
US (4) | US20040015678A1 (en) |
EP (1) | EP1410174A2 (en) |
JP (1) | JP3786644B2 (en) |
KR (1) | KR20040034601A (en) |
AU (1) | AU2002307080A1 (en) |
CA (1) | CA2444968A1 (en) |
NO (1) | NO20034743L (en) |
TW (1) | TW575827B (en) |
WO (1) | WO2002086699A2 (en) |
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030221085A1 (en) * | 2002-05-22 | 2003-11-27 | International Business Machines Corporation | Implementation of thread-static data in multi-threaded computer systems |
US20040109430A1 (en) * | 2002-10-28 | 2004-06-10 | Dacosta Francis | Low cost implementation for high performance embedded systems |
US20060080681A1 (en) * | 2004-10-12 | 2006-04-13 | Majid Anwar | Mechanism to extend functionality in a restricted computing environment |
US20060080682A1 (en) * | 2004-10-12 | 2006-04-13 | Picsel Research Ltd. | Run time dynamic linking |
US20060080680A1 (en) * | 2004-10-12 | 2006-04-13 | Majid Anwar | Platform independent dynamic linking |
US20060080648A1 (en) * | 2004-10-12 | 2006-04-13 | Majid Anwar | Concurrent code loading mechanism |
US20060080683A1 (en) * | 2004-10-12 | 2006-04-13 | Majid Anwar | Mechanism to circumvent restrictions of pre-written code components |
US20060236077A1 (en) * | 2005-04-15 | 2006-10-19 | Oyvind Strom | Microprocessor access of operand stack as a register file using native instructions |
US20070168954A1 (en) * | 2001-04-23 | 2007-07-19 | Atmel Corporation | Microprocessor for executing byte compiled java code |
EP2071455A1 (en) * | 2007-11-09 | 2009-06-17 | Giesecke & Devrient GmbH | Data medium and method for operating a data medium's microprocessor |
US20100088739A1 (en) * | 2008-10-06 | 2010-04-08 | International Business Machines Corporation | Hardware Based Mandatory Access Control |
US20100274991A1 (en) * | 2007-12-28 | 2010-10-28 | Institute Of Computing Technology Of The Chinese Academy Of Sciences | Risc processor device and method of simulating floating-point stack operation thereof |
US20140310696A1 (en) * | 2011-06-08 | 2014-10-16 | Hyperion Core Inc. | Tool-level and hardware-level code optimization and respective hardware modification |
US20160004536A1 (en) * | 2014-07-02 | 2016-01-07 | Freescale Semiconductor Inc. | Systems And Methods For Processing Inline Constants |
US9430200B1 (en) * | 2015-06-04 | 2016-08-30 | Microsoft Technology Licensing Llc | Cross-library framework architecture feature sets |
US20170168472A1 (en) * | 2015-09-29 | 2017-06-15 | Kabushiki Kaisha Toshiba | Information processing apparatus or information communication terminal, and information processing method |
US11500653B2 (en) * | 2020-02-05 | 2022-11-15 | International Business Machines Corporation | Signal handling between programs associated with different addressing modes |
US20230010863A1 (en) * | 2019-12-11 | 2023-01-12 | Arm Limited | Intermodal calling branch instruction |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1447742A1 (en) | 2003-02-11 | 2004-08-18 | STMicroelectronics S.r.l. | Method and apparatus for translating instructions of an ARM-type processor into instructions for a LX-type processor |
US8607299B2 (en) * | 2004-04-27 | 2013-12-10 | Microsoft Corporation | Method and system for enforcing a security policy via a security virtual machine |
KR100597414B1 (en) * | 2004-10-21 | 2006-07-05 | 삼성전자주식회사 | Data processing device and register allocation method using data processing device |
TWI306215B (en) | 2005-04-29 | 2009-02-11 | Ind Tech Res Inst | Method and corresponding apparatus for compiling high-level languages into specific processor architectures |
KR100725393B1 (en) | 2005-05-19 | 2007-06-07 | 삼성전자주식회사 | System and method for reducing execution time of byte code at java virtual machine |
US8458677B2 (en) * | 2009-08-20 | 2013-06-04 | International Business Machines Corporation | Generating code adapted for interlinking legacy scalar code and extended vector code |
US8972705B2 (en) * | 2011-11-16 | 2015-03-03 | Andes Technology Corporation | Executing instructions for managing constant pool base register used for accessing constants during subroutine execution |
US9727353B2 (en) * | 2015-10-30 | 2017-08-08 | International Business Machines Corporation | Simultaneously capturing status information for multiple operating modes |
CN105511942B (en) * | 2015-12-02 | 2019-02-19 | 华为技术有限公司 | The recognition methods of hot spot intermediate code and device in language virtual machine |
US11106463B2 (en) | 2019-05-24 | 2021-08-31 | Texas Instruments Incorporated | System and method for addressing data in memory |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5696959A (en) * | 1993-11-30 | 1997-12-09 | Texas Instruments Incorporated | Memory store from a selected one of a register pair conditional upon the state of a selected status bit |
US5812868A (en) * | 1996-09-16 | 1998-09-22 | Motorola Inc. | Method and apparatus for selecting a register file in a data processing system |
US5937193A (en) * | 1996-11-27 | 1999-08-10 | Vlsi Technology, Inc. | Circuit arrangement for translating platform-independent instructions for execution on a hardware platform and method thereof |
US5978901A (en) * | 1997-08-21 | 1999-11-02 | Advanced Micro Devices, Inc. | Floating point and multimedia unit with data type reclassification capability |
US6021469A (en) * | 1996-01-24 | 2000-02-01 | Sun Microsystems, Inc. | Hardware virtual machine instruction processor |
US6076155A (en) * | 1995-10-24 | 2000-06-13 | S3 Incorporated | Shared register architecture for a dual-instruction-set CPU to facilitate data exchange between the instruction sets |
US6324686B1 (en) * | 1997-11-11 | 2001-11-27 | International Business Machines Corporation | Just in time compiler technique |
US6332215B1 (en) * | 1998-12-08 | 2001-12-18 | Nazomi Communications, Inc. | Java virtual machine hardware for RISC and CISC processors |
US6338160B1 (en) * | 1998-12-08 | 2002-01-08 | Nazomi Communications, Inc. | Constant pool reference resolution method |
US6654954B1 (en) * | 1998-02-17 | 2003-11-25 | International Business Machines Corporation | Computer system, program product and method utilizing executable file with alternate program code attached as a file attribute |
US6826749B2 (en) * | 1998-12-08 | 2004-11-30 | Nazomi Communications, Inc. | Java hardware accelerator using thread manager |
US6990567B1 (en) * | 2000-12-22 | 2006-01-24 | Lsi Logic Corporation | Use of internal general purpose registers of a processor as a Java virtual machine top of stack and dynamic allocation of the registers according to stack status |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19521001A1 (en) * | 1995-06-08 | 1996-12-19 | Siemens Ag | Switchgear unit capable of communication |
US5701508A (en) * | 1995-12-19 | 1997-12-23 | Intel Corporation | Executing different instructions that cause different data type operations to be performed on single logical register file |
JP2000515270A (en) * | 1996-01-24 | 2000-11-14 | サン・マイクロシステムズ・インコーポレイテッド | Dual instruction set processor for execution of instruction sets received from network or local memory |
DE19736904A1 (en) * | 1997-08-25 | 1999-03-04 | Asea Brown Boveri | Power converter circuitry |
CA2444968A1 (en) | 2001-04-23 | 2002-10-31 | Atmel Corporation | Microprocessor for executing byte compiled java code |
-
2002
- 2002-04-01 CA CA002444968A patent/CA2444968A1/en not_active Abandoned
- 2002-04-01 US US10/114,678 patent/US20040015678A1/en not_active Abandoned
- 2002-04-01 JP JP2002584153A patent/JP3786644B2/en not_active Expired - Fee Related
- 2002-04-01 WO PCT/US2002/010389 patent/WO2002086699A2/en active Application Filing
- 2002-04-01 KR KR10-2003-7013746A patent/KR20040034601A/en not_active Application Discontinuation
- 2002-04-01 AU AU2002307080A patent/AU2002307080A1/en not_active Abandoned
- 2002-04-01 EP EP02764161A patent/EP1410174A2/en not_active Withdrawn
- 2002-04-17 TW TW91107844A patent/TW575827B/en not_active IP Right Cessation
-
2003
- 2003-10-23 NO NO20034743A patent/NO20034743L/en not_active Application Discontinuation
-
2007
- 2007-01-04 US US11/619,923 patent/US7917732B2/en not_active Expired - Fee Related
-
2011
- 2011-02-18 US US13/030,984 patent/US8166280B2/en not_active Expired - Lifetime
-
2012
- 2012-04-23 US US13/453,075 patent/US8533433B2/en not_active Expired - Lifetime
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5696959A (en) * | 1993-11-30 | 1997-12-09 | Texas Instruments Incorporated | Memory store from a selected one of a register pair conditional upon the state of a selected status bit |
US6076155A (en) * | 1995-10-24 | 2000-06-13 | S3 Incorporated | Shared register architecture for a dual-instruction-set CPU to facilitate data exchange between the instruction sets |
US6021469A (en) * | 1996-01-24 | 2000-02-01 | Sun Microsystems, Inc. | Hardware virtual machine instruction processor |
US6026485A (en) * | 1996-01-24 | 2000-02-15 | Sun Microsystems, Inc. | Instruction folding for a stack-based machine |
US5812868A (en) * | 1996-09-16 | 1998-09-22 | Motorola Inc. | Method and apparatus for selecting a register file in a data processing system |
US5937193A (en) * | 1996-11-27 | 1999-08-10 | Vlsi Technology, Inc. | Circuit arrangement for translating platform-independent instructions for execution on a hardware platform and method thereof |
US5978901A (en) * | 1997-08-21 | 1999-11-02 | Advanced Micro Devices, Inc. | Floating point and multimedia unit with data type reclassification capability |
US6324686B1 (en) * | 1997-11-11 | 2001-11-27 | International Business Machines Corporation | Just in time compiler technique |
US6654954B1 (en) * | 1998-02-17 | 2003-11-25 | International Business Machines Corporation | Computer system, program product and method utilizing executable file with alternate program code attached as a file attribute |
US6332215B1 (en) * | 1998-12-08 | 2001-12-18 | Nazomi Communications, Inc. | Java virtual machine hardware for RISC and CISC processors |
US6338160B1 (en) * | 1998-12-08 | 2002-01-08 | Nazomi Communications, Inc. | Constant pool reference resolution method |
US6826749B2 (en) * | 1998-12-08 | 2004-11-30 | Nazomi Communications, Inc. | Java hardware accelerator using thread manager |
US6990567B1 (en) * | 2000-12-22 | 2006-01-24 | Lsi Logic Corporation | Use of internal general purpose registers of a processor as a Java virtual machine top of stack and dynamic allocation of the registers according to stack status |
Cited By (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110145548A1 (en) * | 2001-04-23 | 2011-06-16 | Atmel Corporation | Microprocessor for executing byte compiled java code |
US8533433B2 (en) | 2001-04-23 | 2013-09-10 | Atmel Corporation | Microprocessor for executing byte compiled java code |
US20070168954A1 (en) * | 2001-04-23 | 2007-07-19 | Atmel Corporation | Microprocessor for executing byte compiled java code |
US8166280B2 (en) | 2001-04-23 | 2012-04-24 | Atmel Corporation | Microprocessor for executing byte compiled JAVA code |
US7917732B2 (en) | 2001-04-23 | 2011-03-29 | Atmel Corporation | Microprocessor for executing byte compiled JAVA code |
US6915408B2 (en) * | 2002-05-22 | 2005-07-05 | International Business Machines Corporation | Implementation of thread-static data in multi-threaded computer systems |
US20030221085A1 (en) * | 2002-05-22 | 2003-11-27 | International Business Machines Corporation | Implementation of thread-static data in multi-threaded computer systems |
US20040109430A1 (en) * | 2002-10-28 | 2004-06-10 | Dacosta Francis | Low cost implementation for high performance embedded systems |
US20060080681A1 (en) * | 2004-10-12 | 2006-04-13 | Majid Anwar | Mechanism to extend functionality in a restricted computing environment |
US20060080683A1 (en) * | 2004-10-12 | 2006-04-13 | Majid Anwar | Mechanism to circumvent restrictions of pre-written code components |
US20060080648A1 (en) * | 2004-10-12 | 2006-04-13 | Majid Anwar | Concurrent code loading mechanism |
US20060080680A1 (en) * | 2004-10-12 | 2006-04-13 | Majid Anwar | Platform independent dynamic linking |
US20060080682A1 (en) * | 2004-10-12 | 2006-04-13 | Picsel Research Ltd. | Run time dynamic linking |
US7444625B2 (en) | 2004-10-12 | 2008-10-28 | Picsel (Research) Limited | Concurrent code loading mechanism |
WO2006112978A3 (en) * | 2005-04-15 | 2007-06-21 | Atmel Corp | Microprocessor access of operand stack as a register file using native instructions |
US7478224B2 (en) | 2005-04-15 | 2009-01-13 | Atmel Corporation | Microprocessor access of operand stack as a register file using native instructions |
EP1875338A4 (en) * | 2005-04-15 | 2008-07-30 | Atmel Corp | Microprocessor access of operand stack as a register file using native instructions |
EP1875338A2 (en) * | 2005-04-15 | 2008-01-09 | Atmel Corporation | Microprocessor access of operand stack as a register file using native instructions |
WO2006112978A2 (en) | 2005-04-15 | 2006-10-26 | Atmel Corporation | Microprocessor access of operand stack as a register file using native instructions |
US20060236077A1 (en) * | 2005-04-15 | 2006-10-19 | Oyvind Strom | Microprocessor access of operand stack as a register file using native instructions |
EP2071455A1 (en) * | 2007-11-09 | 2009-06-17 | Giesecke & Devrient GmbH | Data medium and method for operating a data medium's microprocessor |
US20100274991A1 (en) * | 2007-12-28 | 2010-10-28 | Institute Of Computing Technology Of The Chinese Academy Of Sciences | Risc processor device and method of simulating floating-point stack operation thereof |
US8788796B2 (en) * | 2007-12-28 | 2014-07-22 | Loongson Technology Corporation Limited | Technique for simulating floating-point stack operation involving conversion of certain floating-point register numbers based on a top-of-stack pointer and modulo function |
US10802990B2 (en) * | 2008-10-06 | 2020-10-13 | International Business Machines Corporation | Hardware based mandatory access control |
US20100088739A1 (en) * | 2008-10-06 | 2010-04-08 | International Business Machines Corporation | Hardware Based Mandatory Access Control |
US9703538B2 (en) * | 2011-06-08 | 2017-07-11 | Hyperion Core, Inc. | Tool-level and hardware-level code optimization and respective hardware modification |
US20140310696A1 (en) * | 2011-06-08 | 2014-10-16 | Hyperion Core Inc. | Tool-level and hardware-level code optimization and respective hardware modification |
US10324723B2 (en) * | 2014-07-02 | 2019-06-18 | Nxp Usa, Inc. | Systems and methods for processing both instructions and constant values from a memory of a digital processor accessed by separate pointers |
US20160004536A1 (en) * | 2014-07-02 | 2016-01-07 | Freescale Semiconductor Inc. | Systems And Methods For Processing Inline Constants |
US20160357531A1 (en) * | 2015-06-04 | 2016-12-08 | Microsoft Technology Licensing, Llc | Cross-library framework architecture feature sets |
US10152309B2 (en) * | 2015-06-04 | 2018-12-11 | Microsoft Technology Licensing, Llc | Cross-library framework architecture feature sets |
US9430200B1 (en) * | 2015-06-04 | 2016-08-30 | Microsoft Technology Licensing Llc | Cross-library framework architecture feature sets |
US20170168472A1 (en) * | 2015-09-29 | 2017-06-15 | Kabushiki Kaisha Toshiba | Information processing apparatus or information communication terminal, and information processing method |
US10691089B2 (en) * | 2015-09-29 | 2020-06-23 | Kabushiki Kaisha Toshiba | Information processing apparatus or information communication terminal, and information processing method |
US20230010863A1 (en) * | 2019-12-11 | 2023-01-12 | Arm Limited | Intermodal calling branch instruction |
US11500653B2 (en) * | 2020-02-05 | 2022-11-15 | International Business Machines Corporation | Signal handling between programs associated with different addressing modes |
Also Published As
Publication number | Publication date |
---|---|
NO20034743D0 (en) | 2003-10-23 |
US7917732B2 (en) | 2011-03-29 |
US20070168954A1 (en) | 2007-07-19 |
NO20034743L (en) | 2003-12-23 |
CA2444968A1 (en) | 2002-10-31 |
WO2002086699A2 (en) | 2002-10-31 |
US8166280B2 (en) | 2012-04-24 |
TW575827B (en) | 2004-02-11 |
US20110145548A1 (en) | 2011-06-16 |
KR20040034601A (en) | 2004-04-28 |
US20120204017A1 (en) | 2012-08-09 |
US8533433B2 (en) | 2013-09-10 |
JP3786644B2 (en) | 2006-06-14 |
JP2004532466A (en) | 2004-10-21 |
WO2002086699A3 (en) | 2004-02-12 |
EP1410174A2 (en) | 2004-04-21 |
AU2002307080A1 (en) | 2002-11-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7917732B2 (en) | Microprocessor for executing byte compiled JAVA code | |
US7478224B2 (en) | Microprocessor access of operand stack as a register file using native instructions | |
JP2834837B2 (en) | Programmable controller | |
US9207958B1 (en) | Virtual machine coprocessor for accelerating software execution | |
KR100618756B1 (en) | Processors and computer systems that execute instruction sets received from network or local memory | |
JP3816961B2 (en) | Data processing apparatus for processing virtual machine instructions | |
KR100412920B1 (en) | High data density risc processor | |
US5933642A (en) | Compiling system and method for reconfigurable computing | |
KR100236527B1 (en) | Single instruction multiple data processing using multiple banks of vector registers | |
US7080362B2 (en) | Java virtual machine hardware for RISC and CISC processors | |
US7243213B2 (en) | Process for translating instructions for an arm-type processor into instructions for a LX-type processor; relative translator device and computer program product | |
JP4171496B2 (en) | Instruction folding processing for arithmetic machines using stacks | |
EP1622009A1 (en) | JSM architecture and systems | |
US20010010072A1 (en) | Instruction translator translating non-native instructions for a processor into native instructions therefor, instruction memory with such translator, and data processing apparatus using them | |
KR20020028814A (en) | Java hardware accelerator using microcode engine | |
WO1999054813A9 (en) | Risc processor with context switch register sets accessible by external coprocessor | |
Glossner et al. | Delft-Java dynamic translation | |
Säntti et al. | Java Co-Processor for Embedded Systems | |
Salamí et al. | Initial evaluation of multimedia extensions on vliw architectures | |
Thomas | Mite: a fast and flexible virtual machine | |
WO1999023549A1 (en) | Direct cache accessing primary operations hierarchically organized to snippets and threads implemented in isa processor |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ATMEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:STROM, OYVIND;REEL/FRAME:012838/0694 Effective date: 20020319 |
|
STCB | Information on status: application discontinuation |
Free format text: EXPRESSLY ABANDONED -- DURING PUBLICATION PROCESS |