US6857063B2 - Data processor and method of operation - Google Patents

Data processor and method of operation Download PDF

Info

Publication number
US6857063B2
US6857063B2 US09/779,886 US77988601A US6857063B2 US 6857063 B2 US6857063 B2 US 6857063B2 US 77988601 A US77988601 A US 77988601A US 6857063 B2 US6857063 B2 US 6857063B2
Authority
US
United States
Prior art keywords
address
value
instruction
predetermined
jump
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.)
Expired - Lifetime, expires
Application number
US09/779,886
Other languages
English (en)
Other versions
US20020112149A1 (en
Inventor
William C. Moyer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
RYO HOLDINGS LLC
Original Assignee
Freescale Semiconductor Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Freescale Semiconductor Inc filed Critical Freescale Semiconductor Inc
Assigned to MOTOROLA, INC. reassignment MOTOROLA, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MOYER, WILLIAM C.
Priority to US09/779,886 priority Critical patent/US6857063B2/en
Priority to CNB018225551A priority patent/CN1318957C/zh
Priority to JP2002564730A priority patent/JP2004527824A/ja
Priority to PCT/US2001/050776 priority patent/WO2002065276A2/en
Priority to AU2002234146A priority patent/AU2002234146A1/en
Priority to EP01985174A priority patent/EP1360582A2/en
Priority to KR1020037010522A priority patent/KR100867564B1/ko
Priority to TW090132540A priority patent/TW586072B/zh
Publication of US20020112149A1 publication Critical patent/US20020112149A1/en
Assigned to FREESCALE SEMICONDUCTOR, INC. reassignment FREESCALE SEMICONDUCTOR, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MOTOROLA, INC
Publication of US6857063B2 publication Critical patent/US6857063B2/en
Application granted granted Critical
Assigned to CITIBANK, N.A. AS COLLATERAL AGENT reassignment CITIBANK, N.A. AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: FREESCALE ACQUISITION CORPORATION, FREESCALE ACQUISITION HOLDINGS CORP., FREESCALE HOLDINGS (BERMUDA) III, LTD., FREESCALE SEMICONDUCTOR, INC.
Assigned to CITIBANK, N.A., AS COLLATERAL AGENT reassignment CITIBANK, N.A., AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: FREESCALE SEMICONDUCTOR, INC.
Assigned to RYO HOLDINGS, LLC reassignment RYO HOLDINGS, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FREESCALE SEMICONDUCTOR, INC
Assigned to FREESCALE SEMICONDUCTOR, INC. reassignment FREESCALE SEMICONDUCTOR, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: CITIBANK, N.A., AS NOTES COLLATERAL AGENT
Assigned to FREESCALE SEMICONDUCTOR, INC., FREESCALE ACQUISITION CORPORATION, FREESCALE ACQUISITION HOLDINGS CORP., FREESCALE HOLDINGS (BERMUDA) III, LTD. reassignment FREESCALE SEMICONDUCTOR, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: CITIBANK, N.A., AS COLLATERAL AGENT
Assigned to FREESCALE SEMICONDUCTOR, INC. reassignment FREESCALE SEMICONDUCTOR, INC. PATENT RELEASE Assignors: CITIBANK, N.A., AS COLLATERAL AGENT
Assigned to FREESCALE SEMICONDUCTOR, INC. reassignment FREESCALE SEMICONDUCTOR, INC. PATENT RELEASE Assignors: CITIBANK, N.A., AS COLLATERAL AGENT
Assigned to FREESCALE SEMICONDUCTOR, INC. reassignment FREESCALE SEMICONDUCTOR, INC. PATENT RELEASE Assignors: CITIBANK, N.A., AS COLLATERAL AGENT
Adjusted expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/32—Address formation of the next instruction, e.g. by incrementing the instruction counter
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3005—Arrangements for executing specific machine instructions to perform operations for flow control
    • G06F9/30058—Conditional branch instructions
    • 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/32—Address formation of the next instruction, e.g. by incrementing the instruction counter
    • G06F9/322—Address formation of the next instruction, e.g. by incrementing the instruction counter for non-sequential address
    • G06F9/323—Address formation of the next instruction, e.g. by incrementing the instruction counter for non-sequential address for indirect branch instructions
    • 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 or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • 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/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482—Procedural
    • G06F9/4484—Executing subprograms
    • G06F9/4486—Formation of subprogram jump address
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators

Definitions

  • the present invention relates to data processing systems, and more particularly, to systems having a software interpreter that implements execution of data processing instructions.
  • Java programming language is an object-oriented high level programming language developed by Sun Microsystems Inc. and designed to be portable enough to be executed on a wide range of computers ranging from small personal computers up to supercomputers.
  • Computer programs written in Java may be compiled into virtual machine instructions for execution by a Java Virtual Machine (JVM).
  • JVM Java Virtual Machine
  • the Java virtual machine is an interpreter that decodes and executes the virtual machine instructions.
  • the virtual machine instructions for the Java virtual machine are bytecodes, meaning they include one or more bytes.
  • the bytecodes are stored in a particular file format called a “class file.”
  • the class file includes a symbol table as well as other ancillary information.
  • a computer program embodied as Java bytecodes in one or more class files is platform independent.
  • the computer program may be executed, unmodified, on any computer that is able to run an implementation of the Java virtual machine.
  • the Java virtual machine is a software emulator of a “generic” computer, which is a major factor in allowing computer programs for the Java virtual machine to be platform independent.
  • the Java virtual machine is commonly implemented as a software interpreter.
  • Conventional interpreters decode and execute the virtual machine instructions of an interpreted program one instruction at a time during execution.
  • Compilers transform virtual machine instructions into native machine instructions prior to execution so that decoding is not performed on virtual machine instructions during execution. Because conventional interpreters repeatedly decode each instruction before it is executed each time the instruction is encountered, execution of interpreted programs is typically quite slower than compiled programs since the native machine instructions of compiled programs can be executed on the native machine or computer system directly.
  • the software interpreter consumes resources (e.g., memory) that will no longer be available to the interpreted program. This is in contrast to compiled programs that execute as native machine instructions so they may be directly executed on the target computer and therefore generally require fewer resources than interpreted programs.
  • resources e.g., memory
  • Java processing function As a JVM to avoid the hardware overhead of a dedicated Java processor or a hardware accelerator (for example, a separate co-processor).
  • a straightforward approach to implementing the JVM and executing a Java program is through the use of a software interpreter.
  • the interpreter implements a software version of a processor in the sense that it performs the standard functions of instruction fetch, decode, and execute of the interpreted instruction stream.
  • the interpreter typically is implemented as a program loop that iterates the fetch, decode, and execute steps.
  • the interpreter As Java instructions (bytecodes) are fetched, the interpreter maintains a virtual program counter (the Java PC), and the decoding of each interpreted Java instruction is performed by a large case statement (switch statement) with clauses corresponding to each binary encoding of the bytecode. Code within each clause performs the actual operation defined by the bytecode.
  • an additional function of the interpreter loop is to maintain a counter that is used in determining when a thread (or task) switch should occur.
  • the threadswitch determination is based on the number of Java bytecodes executed. By keeping a counter value which is modified each time the interpreter loop executes, and comparing it to a predetermined value, the interpreter implements the thread switch logic as well. Maintaining the counter and determining when to threadswitch also creates significant overhead. This overhead significantly limits the operating efficiency of the software interpreter.
  • FIG. 1 Illustrated in FIG. 1 in block diagram form is an illustrative data processing system
  • FIG. 2 Illustrated in FIG. 2 is a known code sequence showing execution flow when a Java program is executed
  • FIG. 3 Illustrated in FIG. 3 is a known diagram of interpreter overhead associated with the Java program execution of FIG. 2 ;
  • FIG. 4 Illustrated in FIG. 4 is a Java program and corresponding emulation code table when the program is executed in accordance with the present invention
  • FIG. 5 Illustrated in FIG. 5 is an example in accordance with the present invention of Java program execution which requires more emulation code than a group size permits;
  • FIG. 6 Illustrated in FIG. 6 is an exemplary emulation code table showing one allocation of instruction slots in accordance with the present invention
  • FIG. 7 Illustrated in FIG. 7 is a Java interpreter instruction explanation for switching instruction flow in a Java program in accordance with the present invention.
  • FIG. 8 Illustrated in FIG. 8 in block diagram form is a portion of the data processor of the system of FIG. 1 for implementing program execution in accordance with the present invention.
  • FIG. 9 Illustrated in FIG. 9 is an exemplary emulation code table showing another allocation of instruction slots in accordance with the present invention.
  • bus will be used to refer to a plurality of signals or conductors that may be used to transfer one or more various types of information, such as data, addresses, control, or status.
  • assert and “negate” will be used when referring to the rendering of a signal, status bit, or similar apparatus into its logically true or logically false state, respectively. If the logically true state is a logic level one, the logically false state will be a logic level zero. And if the logically true state is logic level zero, the logically false state will be a logic level one. In the following description and diagrams, hexadecimal notation is used for some values by pre-pending the value with ‘0x’. Thus the value 0xff corresponds to a decimal value 255 .
  • FIG. 1 is a block diagram that illustrates one embodiment of a data processing system 10 and includes a processor 12 , a co-processor 14 , a co-processor 16 , a memory 18 , other modules 20 and external bus interface 22 which are all bi-directionally connected by way of a bus 28 . Alternate embodiments of the present invention may have only one co-processor 14 , two co-processors 14 and 16 or even more co-processors (not shown). External bus interface 22 is bi-directionally coupled to external bus 26 by way of integrated circuit terminals 35 .
  • Memory 24 is bi-directionally coupled to external bus 26 .
  • Processor 12 may optionally be coupled external to data processing system 10 by way of integrated circuit terminals 31 .
  • Co-processor 14 may optionally be coupled external to data processing system 10 by way of integrated circuit terminals 32 .
  • Memory 18 may optionally be coupled external to data processing system 10 by way of integrated circuit terminals 33 .
  • Other modules 20 may optionally be coupled external to data processing system 10 by way of integrated circuit terminals 34 .
  • Processor 12 is bi-directionally coupled to both co-processor 14 and co-processor 16 by way of co-processor interface 30 . The specific operation of processor 12 within data processing system 10 will be referenced below in the context of Java code execution.
  • FIGS. 2 and 3 an example will be given of a conventional execution flow of instructions in a Java program.
  • An important performance issue in general with known interpreters is the fact that a significant amount of time is spent by the software in changing instruction flow and executing the interpreter overhead routine between each emulated Java bytecode.
  • An illustration in FIG. 2 of instruction execution steps will highlight this point. Note that every identified step of steps one through seven in FIG. 2 requires a change of flow in the software program.
  • one or more software routines such as interpreter overhead 54 must be repetitively jumped to and this creates additional interpreter overhead.
  • FIG. 3 shows the same software routine as FIG.
  • the interpreter overhead software includes fetching, decoding and dispatching a Java bytecode. Dispatching is the step performed to jump to the emulation code corresponding to an emulated Java bytecode.
  • the interpreter overhead also includes software to perform a counter function in order to determine when thread switching should occur.
  • the interpreter overhead 54 software also includes a virtual program counter for the Java Virtual Machine that must be kept updated.
  • FIG. 2 and FIG. 3 show both the Java program bytecodes and the emulation code table that is required by the processor (e.g.
  • processor 12 of FIG. 1 in order to actually execute the bytecodes required by the Java program.
  • the code that is required to perform emulation of a Java bytecode requires two components. The first component is code to actually execute the function (a, f, c,), and the second component is a software routine that returns execution of the emulation code to the interpreter overhead 54 software.
  • the interpreter overhead software illustrated with a bold line, may be a very significant portion of the software that is required to execute a Java bytecode.
  • FIG. 4 there is illustrated one example of a Java program 60 and its corresponding emulation code table 62 that may be executed by processor 12 of FIG. 1 in accordance with one embodiment of the present invention.
  • each Java bytecode has a corresponding group in the emulation code table 62 .
  • each group is correlated to a predetermined opcode of a program, as the present invention is not limited to use only with Java programs.
  • Bytecode execution of bytecodes a, f, c . . . occurs by retrieval in emulation code table 62 of code in the order of steps 1 , 2 and 3 as illustrated.
  • each code group in the emulation code table 62 contains sixteen of the processor 12 instructions.
  • the number sixteen was chosen as a value that provides enough instruction slots to emulate most Java bytecodes, without causing excessive unused slots to be present. Some Java bytecodes will take less than sixteen processor 12 instructions to execute and some will take more. As a result, it should be well understood that alternate embodiments of the present invention may use any number of processor 12 instruction slots for each group. Also, the number of groups may vary according to the number of bytecodes required by the higher-level language.
  • interpreter overhead software is no longer required as a separate routine that must be jumped to by the emulation code.
  • the interpreter overhead required by the prior art as shown in FIG. 2 has been replaced by a block of code used in each group that is labeled “Overhead plus JAVASW”. Note that the “Overhead plus JAVASW” block of code is now distributed throughout the emulation code executed by processor 12 . Note that the software flow illustrated in FIG. 4 and the emulation code table has fewer change of flow steps compared to the prior art illustrated in FIG. 2 .
  • a change of flow is one form of a change of control and that rather than implementing a jump instruction, the operation that may be performed may be another operation where a change of control is implemented, such as transferring between user and supervisor modes.
  • the reduction in the change of flow steps provided by the present invention saves a significant amount of software overhead. It is important to note that the arrows illustrated in both FIG. 2 and FIG. 4 require additional software in order to carry out. Note that although each Java bytecode has been allocated sixteen instruction slots in the embodiment illustrated in FIG. 4 , some particular Java bytecodes will not require all sixteen instruction slots. On the other hand some Java bytecodes require more than sixteen instruction slots in the emulation code. This example will be discussed in FIG. 5 . Thus, FIG.
  • code emulation table 62 that can be executed by processor 12 of FIG. 1 .
  • code emulation table 62 has two hundred fifty-six equal sized groups allocated for the emulation of each Java bytecode as identified by hexadecimal addresses 0x0 through 0xFF.
  • the emulation code table illustrated in FIG. 4 provides a much more contiguous flow when a Java program is executed by processor 12 . This more contiguous flow reduces the amount of software overhead required for the significant number of program flow changes required by the prior art (see FIG. 2 ).
  • FIG. 5 illustrates how the present invention may be used for a Java bytecode which requires more emulation code than the group size allows in emulation code table 63 .
  • Illustrated in FIG. 5 is an emulation code table 63 .
  • the initial portion of the emulation code begins at address 0x67 indicated by an arrow as step 1 .
  • Step 2 indicates that all sixteen instruction slots have been used and yet the corresponding bytecode requires additional emulation code.
  • step 2 indicates that the emulation software flow must move to a new and available block of code in order to finish execution of the Java bytecode.
  • FIG. 5 illustrates how the present invention may be used for a Java bytecode which requires more emulation code than the group size allows in emulation code table 63 .
  • FIG. 5 Illustrated in FIG. 5 is an emulation code table 63 .
  • the initial portion of the emulation code begins at address 0x67 indicated by an arrow as step 1
  • step 2 illustrates a redirection of program execution in the form of a jump of the emulation code to a location past the end of the original emulation code table 62 where a block of code may be located to complete execution of the Java bytecode.
  • This additional code may be any size and is limited only by system resources. The additional code may be stored anywhere in a system where available resources exist to permit storage of the remaining Java bytecode emulation code to be executed. Therefore it should be understood that the selected jump address may be within a predetermined range (0x0 through 0xFF) of addresses which is less than a total range of addresses within the data processing system or the selected jump address may be outside of the predetermined range of addresses for storage anywhere available resources exist.
  • Step 3 shows that once the emulation code for that particular Java bytecode has finished, the emulation code can jump back into any of the groups within the two hundred fifty-six groups at the location where the “Overhead plus JAVASW” software begins.
  • the extra software required at the end of the emulation code table 63 to finish the Java bytecode emulation does not need to include the “Overhead plus JAVASW” software.
  • This operational feature allows reuse of the “Overhead plus JAVASW” software portion of at least one group in the case where a Java bytecode cannot be emulated using only one group in the emulation code table 63 .
  • selecting the number of instruction slots allocated to each group is a significant issue.
  • the selection usually involves a tradeoff between the total size of the emulation code table and the number of Java bytecodes that overflow beyond the group size.
  • the embodiment illustrated in FIG. 6 uses sixteen instruction slots per group, alternate embodiments of the present invention may optimize the group size to a different number of instruction slots. Note that having a group size that is fixed greatly simplifies the address calculation used to point to the emulation code for each emulated bytecode. This may be a significant amount of computation time for processor 12 for each instruction and can significantly impact the overall performance of data processing system 10 .
  • one or more hardware accelerators may be used as part of data processing system 10 (see FIG. 1 , co-processors 14 , 16 ) in order to improve the performance of data processing system 10 .
  • a co-processor is just one type of hardware accelerator that may be used.
  • an IADD (integer add) routine has been illustrated in two ways in order to show how the emulation code table changes based on the presence or absence of a hardware accelerator. The integer add functionality is selected by way of example only.
  • On the left of the “IADD” Routine of FIG. 6 is a software routine 80 that may be executed by processor 12 when a hardware accelerator is not present.
  • the code 82 on the right illustrates a routine which may be executed by processor 12 when a hardware accelerator (e.g. co-processor 14 ), is present.
  • a hardware accelerator e.g. co-processor 14
  • the hardware accelerator may be used to perform a significant portion of the execution of the Java bytecode. Comparing the left and right blocks of code in FIG. 6 , it is apparent to see that a significant number of load and store instructions which previously had to be executed by processor 12 , are no longer required when a hardware accelerator is used. As will be described in further detail in connection with FIG.
  • a user determinable control signal is provided in one form of the invention which permits a system user to select either a first emulation table structure of predetermined code size groupings or a second emulation table structure of differing predetermined code size groupings.
  • the hardware accelerator and the processor must have some type of interface or handshake mechanism in order to communicate and coordinate execution of a Java bytecode.
  • processor 12 and co-processors 14 , 16 communicate by way of co-processor interface 30 . Note that the communications between processor 12 and co-processors 14 , 16 may be complicated by the fact that thread switching may occur in the Java program.
  • processor 12 conditionally signals to coprocessors 14 , 16 whether a valid Java bytecode is to be executed or not, based upon whether or not thread switching is to occur.
  • co-processor interface 30 may also include snooping or broadcast signals to allow processor 12 and coprocessors 14 , 16 to have visibility into the software flow being performed by the other.
  • emulation code table 72 of FIG. 6 includes two hundred fifty-six addressable groups (0x0 through 0xff), where each group is allocated to a corresponding Java bytecode. It is desirable to locate the emulation code to implement the Java thread switching in the emulation code table. Due to the fixed number of instruction slots in each group, there is no unallocated memory location in the emulation code table 72 that is available to use for the thread switching software. Thus, it is necessary to use unused instruction slots within one or more groups to locate the thread switching code. In one embodiment of the present invention, the thread switching software routine is located in the first group that corresponds to Java bytecode zero (0).
  • this group is allocated to the no-operation (NOP) instruction that requires, by way of example, only four instruction slots, there are twelve unused instruction slots remaining to store at least a portion of the software routine for performing thread switching. Note that if the thread switching routine does not fit within the allocated slots, a jump may be made to a location past the end of emulation code table 72 as was described in FIG. 5 for emulation code table 63 . Alternate embodiments of the present invention may locate the software for performing thread switching in other locations within emulation code table 72 . Note that using this first group in the emulation code table 72 to locate the thread switching software allows the hardware for implementing the JAVASW instruction (to be described further herein) to be implemented in a more straightforward manner using hardware in processor 12 .
  • FIG. 7 illustrates further details of the “JAVASW” instruction previously referenced in the emulation tables of FIGS. 4 and 5 .
  • the JAVASW instruction is an instruction that is executed by processor 12 (see FIG. 1 ).
  • FIG. 8 Illustrated in FIG. 8 is an instruction register 116 .
  • Instruction decode 104 has an input for receiving a processor 12 instruction from instruction register 116 by way of conductors 117 connected to an output of instruction register 116 , and an output connected to an input of a control circuitry 105 .
  • Control circuitry 105 also receives at an input 118 a Java bytecode to be executed.
  • control circuitry 105 is connected to a control input of a multiplexer (Mux) and combiner 106 , to input/output terminals of registers 107 having a program counter 108 and other registers 109 , to an input/output a, terminal of an arithmetic logic unit (ALU) 110 , and to an input/output terminal of an address select logic 111 via conductors 130 .
  • Increment circuitry 112 has an output connected to a first input of address select logic 111 via conductors 120 .
  • a Jump Address 121 is connected to a second input of address select logic 111 .
  • An Exception Address 122 is connected to a third input of address select logic 111
  • a Branch Address 123 is connected to a fourth input of address select logic 111
  • An output of Mux and combiner 106 is connected to a fifth input of address select logic 111 for providing a JAVASW Program Counter Address 124 .
  • Conductors 133 are connected to an input of increment circuitry 112 , to an output of address select logic 111 , and to an input/output terminal of program counter 108 for communication to and from control circuitry 105 .
  • Jump Address 121 , Exception Address 122 and Branch Address 123 are provided by control circuitry 105 .
  • the Mux and combiner 106 has an input for receiving a Constant 0x8 100 , an input having a value equal to R 4 ⁇ 1 (a value in a register R 4 of registers 109 which is left-shifted by one) 101 , an input having a value equal to R 4 ⁇ 5 (a value in register R 4 of registers 109 which is left-shifted by five) 102 , an Entry Point Outside of Table 103 , and an input for receiving the program counter value plus 2 (PC+2).
  • Control circuitry 105 has an additional input for receiving a Switch Thread Threshold value by way of one or more conductors 134 .
  • the operation of one embodiment of the JAVASW instruction is described in the form of ‘quasi-C’ code.
  • the JAVASW instruction causes a jump to a bytecode emulation sequence.
  • An equation 92 illustrates the manner in which the address of this bytecode emulation sequence is calculated.
  • the portion of equation 92 contained within brackets indicates the jump address that is loaded into program counter 108 (PC) of registers 107 during execution of the JAVASW instruction.
  • PC program counter 108
  • This value is provided by Mux and combiner 106 in FIG. 8 to address select logic 111 by way of conductors 124 .
  • the value “PC+2” of equation 92 is the program counter value after program counter 108 has been incremented by increment circuitry 112 .
  • This incrementing occurs as a natural step in the execution pipeline of processor 12 , and thus is convenient to use as a base address value.
  • a non-incremented program counter value PC may be used instead.
  • the incremented program value is then logically ANDed with the value 0xffffe000.
  • This Boolean operation has the effect of forcing the low order thirteen bits of the value of (PC+2) to be forced to zero.
  • the resulting address points to the first instruction slot of the first bytecode instruction group in emulation code table 72 (see FIG. 6 ). Note that in some embodiments of the present invention a logical AND may not be required. Instead, the low order thirteen bits of the value PC+2 may be truncated.
  • this pointer value may be logically ORed with the Java bytecode value stored in Register R 4 that is one of registers 109 , shifted by an amount corresponding to the group size.
  • This described operation effectively indexes the new program counter address into the correct location within emulation table 72 so that the program counter register now points to the beginning of the correct instruction group for the Java bytecode that is to be emulated by processor 12 .
  • An alternate method of forming the pointer value is to simply concatenate the high order eighteen bits of PC+2 with the Java bytecode value stored in Register R 4 and then pad the result with 5 bits of zeros to form a 32 bit address. Note that the jump address may be formed in a wide variety of ways.
  • the result is always an address that points to the beginning of the correct instruction group within emulation code table 72 (see FIG. 6 ) that corresponds to the current Java bytecode.
  • equation 92 is used to calculate the jump address if thread switching is not occurring. Note that thread switching does not occur if a statement 91 is true.
  • Statement 91 is measuring whether a switch count (SWCOUNT) threshold (the point when a change of program tasks should be implemented by the data processing system) has been crossed in order to determine if a change to another Java thread should occur. Therefore, statement 91 requires a comparison determination of a value, such as a count value for example, with a predetermined value, the switch count threshold value.
  • SWCOUNT switch count
  • statements 91 and 93 may be any type of variable conditions that select one of a plurality of possible jump destination addresses. It should be further appreciated that statement 95 is optional and may not be used in some embodiments.
  • Instruction format 90 illustrated in FIG. 7 may also be referred to as an opcode.
  • instruction format 90 is held in instruction register 116 , decoded by instruction decode 104 circuitry of FIG. 8 , and consequently provided to control circuitry 105 in order to execute the JAVASW instruction in processor 12 .
  • the jump operation that is performed during the JAVASW instruction always occurs.
  • the jump is not optional or conditional, but always occurs to one of a plurality of jump destination addresses.
  • R 4 ⁇ 5 indicates that a predetermined value, in this case the bytecode value, is left shifted by five bits before it is loaded into register R 4 .
  • each instruction is sixteen bits in length, thus occupying 2 bytes of storage.
  • a left shift of five bits is equal to a multiplication by 32 bytes, or sixteen instructions.
  • the reason the bytecode value is shifted by five, or multiplied by thirty-two, is to allow the offset into emulation code table 72 to index to the correct bytecode instruction group within emulation code table 72 .
  • the value R 4 ⁇ 5 is used to move the jump destination address pointer to the beginning of the correct group within emulation code table 72 .
  • alternate embodiments of the present invention could include the implementation of the JAVASW instruction functionality using more than one instruction.
  • the JAVASW instruction combines the ability to control a counter and to implement a table jump in a single instruction. This is shown in FIG. 7 as statement 95 that is performed in addition to one of equations 92 or 94 . Note that for the JAVASW instruction a change of instruction flow is always taken, which is not the case for a conditional branch instruction. Note that the jump performed in response to the JAVASW instruction is to one of two addresses, both of which are within a predetermined table (see emulation code table 62 in FIG. 4 ).
  • the JAVASW instruction performs a table jump operation where the destination of the table jump is a function of both the Java bytecode value and a counter value.
  • the counter value may be the switch count value (SWCOUNT in FIG. 7 ) used by the Java interpreter to determine when thread switching should occur.
  • SWCOUNT switch count value
  • one of registers 109 may be used as a counter. Alternate embodiments may use a combination of hardware or software and hardware in processor 12 to implement this switch counter function.
  • the counter value conditionally causes the normal entry point of the jump to be over-ridden with a predetermined fixed entry point back into the emulation table (illustrated as 0x8 in FIGS.
  • the normal table entry point corresponds to the address calculation of the PC value determined by execution of equation 92 , and occurs when no thread switching is to occur.
  • the normal table entry point corresponding to equation 92 is not used. Instead, it is over-ridden with the entry point defined by equation 94 , as a threadswitch should now be performed, and the emulation code for the Java bytecode that would normally have been emulated is no longer entered.
  • the JAVASW instruction provides an instruction that conditionally signals a hardware accelerator (e.g. co-processors 14 , 16 ) via a handshake signal (part of co-processor interface 30 ) when a non-over-ridden table entry point is used.
  • This handshake signal allows the hardware accelerator to determine whether processor 12 is executing equation 92 in FIG. 7 (in which case the bytecode is to be emulated by processor 12 and the hardware accelerator) or whether processor 12 is thread switching by executing equation 94 in FIG. 7 (in which case the hardware accelerator must not perform emulation of the current bytecode).
  • the JAVASW instruction may provide a dispatch mechanism that allows the normal table structure shown in FIG. 6 to be over-ridden for a small set of bytecode values. For example, for a commonly executed Java bytecode that requires more than sixteen instruction slots, and thus would overflow the allocated group size, hardware may be provided which forces the JAVASW instruction to jump to a location which is outside of the emulation code table to execute the code required by the Java bytecode. Note that the only hardware required to implement such a dispatch mechanism is a small amount of decode logic to decode a selected set of Java bytecodes which would overflow their allocated instruction slots, and the additional input 103 to Mux and combiner 106 in FIG.
  • this decode circuitry may be implemented within control circuitry 105 of processor 12 as is described below in connection with FIG. 8 .
  • FIG. 8 illustrates but one embodiment of the relevant portion of processor 12 of FIG. 1 .
  • the instructions used to emulate a Java bytecode are received by instruction decode circuitry 104 from instruction register 116 .
  • Instruction decode circuitry 104 decodes the emulation instructions and provides the decoded result to control circuitry 105 .
  • Control circuitry 105 provides control signals to other elements within processor 12 in order to execute these instructions. As indicated above, control circuitry 105 is bi-directionally connected to registers 107 , arithmetic logic unit (ALU) 110 and address select logic 111 by way of conductors 130 . Control circuitry 105 provides control signals to Mux and combiner 106 .
  • ALU arithmetic logic unit
  • Alternate embodiments of the present invention may use more, fewer, or different inputs to Mux and combiner 106 .
  • the output of Mux and combiner 106 is a JAVASW program counter address 124 that is provided as an input to address select logic 111 .
  • Address select logic 111 also receives branch address 123 , exception address 122 , and jump address 121 as inputs.
  • the output of address select logic 111 may be incremented by increment circuitry 112 and then fed back in as an input to address select logic 111 by way of conductors 120 .
  • increment circuitry 112 increments the address by two bytes, which is equivalent to one instruction.
  • Alternate embodiments of the present invention may use increment circuitry 112 to increment the address by various amounts.
  • the address output by address select logic 111 is provided to program counter 108 and to control circuitry 105 by way of conductors 133 .
  • Control circuitry 105 is used to generate jump address 121 , exception address 122 , and branch address 123 .
  • Control circuitry 105 receives one or more switch thread threshold signals by way of one or more conductors 134 .
  • registers 107 are bi-directionally connected to arithmetic logic unit 110 by way of conductors 130 , 131 , and 132 .
  • Input 113 to Mux and combiner 106 provides the current PC+2 value from program counter 108 that is used to form various JAVASW program counter address 124 values in combination with other inputs to Mux and combiner 106 .
  • the input 100 that provides the constant 0x8 can be used in combination with input 113 to force the JAVASW program counter address to point to the thread switching software routine 76 that is located in the first group of the emulation code table 72 in FIG. 6 . This new program counter address will be used when the thread switching software is required.
  • Input 101 to Mux and combiner 106 indicates that the contents of register R 4 are left shifted one digit location and that shift is equivalent to multiplying by two. Input 101 is used to form the new program counter address when a group in emulation code table 72 contains a single instruction to store a jump address past the end of the emulation code table 72 where the emulation code to implement the corresponding bytecode is located. This functionality will be further illustrated in the description below of FIG. 9 . Input 102 to Mux and combiner 106 indicates a left shift by five of the contents of register R 4 which is equivalent to a multiply by 32 . The left shifted value R 4 ⁇ 5 is used in combination with input 113 to select between groups in the emulation code table 72 .
  • Such a shift is an adjust that is performed to generate a new program counter address when processor 12 is finishing execution of a previous Java bytecode and transferring to execution of a next Java bytecode.
  • Input 103 to Mux and combiner 106 allows the normal table structure to be overridden for a small set of bytecode values. In other words, an address outside of emulation code table 72 may be forced to a predetermined value by way of the Entry Point Outside Of Table 103 signal input to the Mux and combiner 106 .
  • alternate embodiments of the present invention may have other inputs to Mux and combiner 106 which are used to create different new program counter addresses based on the needs of data processing system 10 .
  • the inputs to Mux and combiner 106 may be used to vary the group sizes within emulation code table 72 .
  • the illustrated embodiment has been shown with one standard group size, alternate embodiments of the present invention may use a different group size or a plurality of group sizes defined by the inputs to Mux and combiner 106 . This provides the user of data processor system 10 with a significant amount of flexibility in determining the length of code required to emulate various bytecodes of a high level language such as Java.
  • FIG. 9 illustrates a dispatch mechanism that allows an emulation code table to be compressed for a large group of bytecode values.
  • the corresponding emulation code may require more instruction slots than the group size provides.
  • the overhead associated with step 2 and 3 in FIG. 5 may possibly be simplified if the emulation code remains in a contiguous sequence.
  • an alternate emulation code table 83 in FIG. 9 may be desirable. Accordingly, FIG.
  • emulation code table 83 as a storage device which contains two hundred and fifty-six entries (one group per bytecode) in which the first one hundred and ninety-two entries (3 ⁇ 4 of the entries) have a group size of sixteen instruction slots, (entries corresponding to bytecodes 0x0 through 0xbf), and the final sixty-four entries (1 ⁇ 4 of the entries) have a group size of one instruction slot.
  • entries for bytecodes 0x0 through 0xbf are utilized as previously described with reference to FIGS. 5 and 6
  • entries for bytecodes 0xc0 through 0xff contain a jump instruction to the actual emulation code for the corresponding bytecode.
  • This structure allows the table to be compressed in size, and the emulation code for these more complex bytecodes can remain contiguous, rather than being divided into an initial portion and a final portion as was done in FIG. 5 .
  • This dispatch mechanism simplifies the code and reduces the overhead by removing the need for performing steps 2 and 3 in FIG. 5 .
  • an alternate step 2 is introduced which jumps directly to the entire emulation routine for a Java bytecode in the range 0xc0 through 0xff.
  • this table compression is accomplished by utilizing input 101 to Mux and combiner 106 in conjunction with PC+2 input 113 , and control circuitry 105 .
  • Control circuitry 105 may further implement a user determinable control signal through the use of the Java btyecode received at input 1118 .
  • the control signal selects either a first emulation table structure of predetermined group sizes or a second emulation table structure of predetermined group sizes and provides a user flexibility as to whether to operate with a storage device organized such as FIG. 5 or a storage device organized such as FIG. 9 .
  • FIG. 9 shows a particular selection of bytecodes 0xc0 through 0xff as bytecodes to have compressed table entries, alternate bytecode groups may be selected, or a different number of bytecodes may be selected for compressed table entries in accordance with the present invention.
  • the instruction in one form, may be stored on a storage medium either within an integrated circuit chip or independent and separate from an integrated circuit chip.
  • the hardware support for the instruction allows optimization of memory used to implement the interpreter function. As a result, overhead in the form of execution time, amount of hardware resources required and amount of interpreter software required has been significantly reduced.
  • the present invention combines controlling a counter and implementing a table jump wherein a change of flow is always taken.
  • the JAVASW instruction implements the destination of a table jump as a function of both a bytecode value and a counter value, the counter value conditionally causing the normally calculated entry point in the table to be overridden with a predetermined fixed entry point.
  • the JAVASW instruction also conditionally signals a hardware accelerator via a handshake signal when a thread switch is not being implemented.
  • a dispatch mechanism is provided which allows a normal memory structure to be overridden for a small set of bytecode values.
  • the memory table may be configured to support multiple group sizes (e.g. 2, 8, 16 bytes, etc.) corresponding to simple and complex bytecodes. In such a bifurcation, the opcode (bytecode) is decoded and the code is selectively separated based on group size.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Devices For Executing Special Programs (AREA)
  • Executing Machine-Instructions (AREA)
US09/779,886 2001-02-09 2001-02-09 Data processor and method of operation Expired - Lifetime US6857063B2 (en)

Priority Applications (8)

Application Number Priority Date Filing Date Title
US09/779,886 US6857063B2 (en) 2001-02-09 2001-02-09 Data processor and method of operation
AU2002234146A AU2002234146A1 (en) 2001-02-09 2001-12-18 Apparatus and method for effecting changes in program control flow
JP2002564730A JP2004527824A (ja) 2001-02-09 2001-12-18 データプロセッサ及び処理方法
PCT/US2001/050776 WO2002065276A2 (en) 2001-02-09 2001-12-18 Apparatus and method for effecting changes in program control flow
CNB018225551A CN1318957C (zh) 2001-02-09 2001-12-18 在程序控制流中实现改变的装置和方法
EP01985174A EP1360582A2 (en) 2001-02-09 2001-12-18 Apparatus and method for effecting changes in program control flow
KR1020037010522A KR100867564B1 (ko) 2001-02-09 2001-12-18 프로그램 제어 흐름에서 변경들을 이루기 위한 장치 및 방법
TW090132540A TW586072B (en) 2001-02-09 2001-12-27 Data processor and method of operation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/779,886 US6857063B2 (en) 2001-02-09 2001-02-09 Data processor and method of operation

Publications (2)

Publication Number Publication Date
US20020112149A1 US20020112149A1 (en) 2002-08-15
US6857063B2 true US6857063B2 (en) 2005-02-15

Family

ID=25117889

Family Applications (1)

Application Number Title Priority Date Filing Date
US09/779,886 Expired - Lifetime US6857063B2 (en) 2001-02-09 2001-02-09 Data processor and method of operation

Country Status (8)

Country Link
US (1) US6857063B2 (zh)
EP (1) EP1360582A2 (zh)
JP (1) JP2004527824A (zh)
KR (1) KR100867564B1 (zh)
CN (1) CN1318957C (zh)
AU (1) AU2002234146A1 (zh)
TW (1) TW586072B (zh)
WO (1) WO2002065276A2 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040088703A1 (en) * 2002-11-05 2004-05-06 Nedim Fresko Mechanism for implementing an interpreter with hierarchical execution loops
US20050050528A1 (en) * 2003-07-03 2005-03-03 International Business Machines Corporation Method and apparatus to guarantee type and initialization safety in multithreaded programs
KR100678912B1 (ko) * 2005-10-18 2007-02-05 삼성전자주식회사 메소드 바이트코드 해석 방법 및 상기 방법에 의해동작하는 시스템
US7584344B2 (en) 2006-05-02 2009-09-01 Freescale Semiconductor, Inc. Instruction for conditionally yielding to a ready thread based on priority criteria
US9823927B2 (en) 2012-11-30 2017-11-21 Intel Corporation Range selection for data parallel programming environments

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ITRM20030354A1 (it) 2003-07-17 2005-01-18 Micron Technology Inc Unita' di controllo per dispositivo di memoria.
US8627303B2 (en) 2009-11-30 2014-01-07 International Business Machines Corporation Memory optimization of virtual machine code by partitioning extraneous information
US8713348B2 (en) 2010-08-30 2014-04-29 Mediatek Inc. Apparatus for performing timer management regarding a system timer scheduler service, and associated method
US20160179542A1 (en) * 2014-12-23 2016-06-23 Patrick P. Lai Instruction and logic to perform a fused single cycle increment-compare-jump
US11385897B2 (en) * 2019-10-01 2022-07-12 Marvell Asia Pte, Ltd. Merge execution unit for microinstructions
CN118519637A (zh) * 2023-02-17 2024-08-20 华为技术有限公司 一种编译方法、解析方法和装置

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3571804A (en) * 1967-08-31 1971-03-23 Ericsson Telefon Ab L M Method for execution of jumps in an instruction memory of a computer
EP0221577A2 (en) 1985-11-08 1987-05-13 Nec Corporation Microprogram control unit
US4755935A (en) * 1986-01-27 1988-07-05 Schlumberger Technology Corporation Prefetch memory system having next-instruction buffer which stores target tracks of jumps prior to CPU access of instruction
US5434985A (en) 1992-08-11 1995-07-18 International Business Machines Corporation Simultaneous prediction of multiple branches for superscalar processing
US5632028A (en) * 1995-03-03 1997-05-20 Hal Computer Systems, Inc. Hardware support for fast software emulation of unimplemented instructions
WO1999031579A2 (en) 1997-12-15 1999-06-24 Motorola Inc. Computer instruction which generates multiple data-type results
US6009261A (en) * 1997-12-16 1999-12-28 International Business Machines Corporation Preprocessing of stored target routines for emulating incompatible instructions on a target processor
US6021273A (en) 1997-06-30 2000-02-01 Sun Microsystems, Inc. Interpreter generation and implementation utilizing interpreter states and register caching
US6070220A (en) 1996-12-09 2000-05-30 Kabushiki Kaisha Toshiba Jump code generator, interrupt program selection system, interruption program selection method, and computer with the function
US6148437A (en) 1998-05-04 2000-11-14 Hewlett-Packard Company System and method for jump-evaluated trace designation
US6170998B1 (en) * 1995-05-11 2001-01-09 Matsushita Electric Industrial Co., Ltd. Processor which returns from a subroutine at high speed and a program translating apparatus which generates machine programs that makes a high-speed return from a subroutine
US6233678B1 (en) * 1998-11-05 2001-05-15 Hewlett-Packard Company Method and apparatus for profiling of non-instrumented programs and dynamic processing of profile data

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE2921430A1 (de) * 1979-05-26 1980-12-04 Haarmann & Reimer Gmbh 3-methyl-5-keto- alpha , omega -alken- dicarbonsaeuren, verfahren zu ihrer herstellung und ihre verwendung zur herstellung makrocyclischer beta -methyl-ketone

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3571804A (en) * 1967-08-31 1971-03-23 Ericsson Telefon Ab L M Method for execution of jumps in an instruction memory of a computer
EP0221577A2 (en) 1985-11-08 1987-05-13 Nec Corporation Microprogram control unit
US4755935A (en) * 1986-01-27 1988-07-05 Schlumberger Technology Corporation Prefetch memory system having next-instruction buffer which stores target tracks of jumps prior to CPU access of instruction
US5434985A (en) 1992-08-11 1995-07-18 International Business Machines Corporation Simultaneous prediction of multiple branches for superscalar processing
US5632028A (en) * 1995-03-03 1997-05-20 Hal Computer Systems, Inc. Hardware support for fast software emulation of unimplemented instructions
US6170998B1 (en) * 1995-05-11 2001-01-09 Matsushita Electric Industrial Co., Ltd. Processor which returns from a subroutine at high speed and a program translating apparatus which generates machine programs that makes a high-speed return from a subroutine
US6070220A (en) 1996-12-09 2000-05-30 Kabushiki Kaisha Toshiba Jump code generator, interrupt program selection system, interruption program selection method, and computer with the function
US6021273A (en) 1997-06-30 2000-02-01 Sun Microsystems, Inc. Interpreter generation and implementation utilizing interpreter states and register caching
WO1999031579A2 (en) 1997-12-15 1999-06-24 Motorola Inc. Computer instruction which generates multiple data-type results
US6009261A (en) * 1997-12-16 1999-12-28 International Business Machines Corporation Preprocessing of stored target routines for emulating incompatible instructions on a target processor
US6148437A (en) 1998-05-04 2000-11-14 Hewlett-Packard Company System and method for jump-evaluated trace designation
US6233678B1 (en) * 1998-11-05 2001-05-15 Hewlett-Packard Company Method and apparatus for profiling of non-instrumented programs and dynamic processing of profile data

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
European Patent Office, IBM Technical Disclosure Bulletin, Apr. 1983.
PCT Written Opinion.
PCT/US01/50776 PCT Search Report mailed Aug. 14, 2002.
Stallings, Willian, "Computer Organization and Architecture", pp. 581-583, 5th edition, 1999.* *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040088703A1 (en) * 2002-11-05 2004-05-06 Nedim Fresko Mechanism for implementing an interpreter with hierarchical execution loops
US20050050528A1 (en) * 2003-07-03 2005-03-03 International Business Machines Corporation Method and apparatus to guarantee type and initialization safety in multithreaded programs
US7434212B2 (en) * 2003-07-03 2008-10-07 International Business Machines Corporation Method and apparatus to guarantee type and initialization safety in multithreaded programs
US20090037891A1 (en) * 2003-07-03 2009-02-05 International Business Machines Corporation Apparatus to guarantee type and initialization safety in multithreaded programs
US8271965B2 (en) 2003-07-03 2012-09-18 International Business Machines Corporation Apparatus to guarantee type and initialization safety in multithreaded programs
KR100678912B1 (ko) * 2005-10-18 2007-02-05 삼성전자주식회사 메소드 바이트코드 해석 방법 및 상기 방법에 의해동작하는 시스템
US7584344B2 (en) 2006-05-02 2009-09-01 Freescale Semiconductor, Inc. Instruction for conditionally yielding to a ready thread based on priority criteria
US9823927B2 (en) 2012-11-30 2017-11-21 Intel Corporation Range selection for data parallel programming environments

Also Published As

Publication number Publication date
KR20030077612A (ko) 2003-10-01
CN1531680A (zh) 2004-09-22
AU2002234146A1 (en) 2002-08-28
JP2004527824A (ja) 2004-09-09
CN1318957C (zh) 2007-05-30
TW586072B (en) 2004-05-01
EP1360582A2 (en) 2003-11-12
KR100867564B1 (ko) 2008-11-10
WO2002065276A2 (en) 2002-08-22
US20020112149A1 (en) 2002-08-15
WO2002065276A3 (en) 2003-05-15

Similar Documents

Publication Publication Date Title
JP3797471B2 (ja) マルチスレッドｖｌｉｗプロセッサにおける分割可能なパケットを識別するための方法および装置
US5748950A (en) Method and apparatus for providing an optimized compare-and-branch instruction
KR100715055B1 (ko) Ｖｌｉｗ 프로세서, 인스트럭션 컴파일 방법, 머신 판독가능한 매체 및 컴퓨터 프로그램 실행 방법
US5077657A (en) Emulator Assist unit which forms addresses of user instruction operands in response to emulator assist unit commands from host processor
US20050283589A1 (en) Data processor
KR100705507B1 (ko) 확장가능한 프로세서 아키텍처에 진보된 명령어들을부가하는 방법 및 장치
US20040073773A1 (en) Vector processor architecture and methods performed therein
US5983336A (en) Method and apparatus for packing and unpacking wide instruction word using pointers and masks to shift word syllables to designated execution units groups
EP1267256A2 (en) Conditional execution of instructions with multiple destinations
JP2006185462A (ja) 高データ密度のｒｉｓｃプロセッサ
KR19980032264A (ko) 벡터 프로세서 프로그래밍 및 벡터 프로세서와 risc 프로세서를 구비하는 비대칭 이중 프로세서의 병렬 프로그래밍
US20120284489A1 (en) Methods and Apparatus for Constant Extension in a Processor
US6857063B2 (en) Data processor and method of operation
US6292845B1 (en) Processing unit having independent execution units for parallel execution of instructions of different category with instructions having specific bits indicating instruction size and category respectively
WO2010112970A1 (en) Data processing with variable operand size
EP0745932B1 (en) Microprocessor supporting variable length instruction execution
JP2015133129A (ja) 命令としてデータ値を評価するシステムおよび方法
US4812971A (en) Central processing unit for a digital computer
KR100267092B1 (ko) 멀티미디어신호프로세서의단일명령다중데이터처리
US8285975B2 (en) Register file with separate registers for compiler code and low level code
US6681319B1 (en) Dual access instruction and compound memory access instruction with compatible address fields
EP0992892B1 (en) Compound memory access instructions
JPH1115660A (ja) マイクロプロセッサ
CN116848506A (zh) 存储器复制大小确定指令和数据传送指令
Choe et al. A VLSI multistreaming RISC processor

Legal Events

Date Code Title Description
AS Assignment

Owner name: MOTOROLA, INC., ILLINOIS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOYER, WILLIAM C.;REEL/FRAME:011570/0865

Effective date: 20010207

AS Assignment

Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOTOROLA, INC;REEL/FRAME:015360/0718

Effective date: 20040404

Owner name: FREESCALE SEMICONDUCTOR, INC.,TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MOTOROLA, INC;REEL/FRAME:015360/0718

Effective date: 20040404

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: CITIBANK, N.A. AS COLLATERAL AGENT, NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNORS:FREESCALE SEMICONDUCTOR, INC.;FREESCALE ACQUISITION CORPORATION;FREESCALE ACQUISITION HOLDINGS CORP.;AND OTHERS;REEL/FRAME:018855/0129

Effective date: 20061201

Owner name: CITIBANK, N.A. AS COLLATERAL AGENT,NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNORS:FREESCALE SEMICONDUCTOR, INC.;FREESCALE ACQUISITION CORPORATION;FREESCALE ACQUISITION HOLDINGS CORP.;AND OTHERS;REEL/FRAME:018855/0129

Effective date: 20061201

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: CITIBANK, N.A., AS COLLATERAL AGENT,NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC.;REEL/FRAME:024397/0001

Effective date: 20100413

Owner name: CITIBANK, N.A., AS COLLATERAL AGENT, NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC.;REEL/FRAME:024397/0001

Effective date: 20100413

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 8

AS Assignment

Owner name: RYO HOLDINGS, LLC, DELAWARE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:FREESCALE SEMICONDUCTOR, INC;REEL/FRAME:028139/0475

Effective date: 20120329

AS Assignment

Owner name: FREESCALE ACQUISITION CORPORATION, TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:028331/0948

Effective date: 20120330

Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:028331/0948

Effective date: 20120330

Owner name: FREESCALE HOLDINGS (BERMUDA) III, LTD., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:028331/0948

Effective date: 20120330

Owner name: FREESCALE ACQUISITION HOLDINGS CORP., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:028331/0948

Effective date: 20120330

Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CITIBANK, N.A., AS NOTES COLLATERAL AGENT;REEL/FRAME:028331/0957

Effective date: 20120330

AS Assignment

Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS

Free format text: PATENT RELEASE;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:037354/0225

Effective date: 20151207

Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS

Free format text: PATENT RELEASE;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:037356/0553

Effective date: 20151207

Owner name: FREESCALE SEMICONDUCTOR, INC., TEXAS

Free format text: PATENT RELEASE;ASSIGNOR:CITIBANK, N.A., AS COLLATERAL AGENT;REEL/FRAME:037356/0143

Effective date: 20151207

FPAY Fee payment

Year of fee payment: 12