WO2001079995A2

WO2001079995A2 - Method for making efficient service calls to a hardware coprocessor using load and/or store instructions

Info

Publication number: WO2001079995A2
Application number: PCT/US2001/011213
Authority: WO
Inventors: John E. Derrick; Robert G. Mcdonald; Barry D. Williamson
Original assignee: Chicory Systems, Inc.
Priority date: 2000-04-05
Filing date: 2001-04-05
Publication date: 2001-10-25
Also published as: AU5320001A; WO2001079995A3

Abstract

A coprocessor has a service port architecture which may support multiple service ports, each of which may be assigned to a different process. Operations supported by the coprocessor may be requested using commands to the service port, and status may be checked using status commands to the service port. Since different processes may be assigned to different service ports, the coprocessor may be able to determine, while performing an operation for a process, that a different process is requesting an operation. In one embodiment, the coprocessor may interrupt the in-progress operation to perform the newly requested operation. When status is requested for the interrupted operation, the coprocessor may return a failure status code indicating the interrupted operation was interrupted. In one embodiment, when the coprocessor initiates an operation for a service port, the coprocessor establishes a reservation for that service port. If a reservation for a service port is inactive when a status command is received on that service port, then the coprocessor may indicate that the operation failed (was unsuccessful) due to interruption by another operation from a different service port. In one embodiment, the coprocessor may support the locking of one or more resources which may store the output of an operation. If another operation would use the resources locked to a service port, that operation may be terminated with a failure status indicating that the resources used are locked to another service port.

Description

TITLE: METHOD FOR MAKING EFFICIENT SERVICE CALLS TO A HARDWARE COPROCESSOR USING LOAD AND/OR STORE INSTRUCTIONS

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention is related to the field of coprocessors and, more particularly, to mechanisms for communicating between a processor and coprocessor.

2. Description of the Related Art

Generally, computer systems include a central processing unit (CPU) to control the operation of the various components in the system and to perform the bulk of the computing tasks for the computer system. Additionally, various computer systems have employed coprocessors to accelerate one or more operations performed in the computer system. As used herein, a coprocessor is hardware circuitry designed to perform one or more operations under the control of a CPU. .The operations may, for example, be operations which would require a relatively large number of instructions to perform in the CPU (and thus may take a long time to perform). The coprocessor may perform the operation, and thus the time the CPU would otherwise spend performing the operation may be spent on other tasks. The coprocessor may perform the operation more efficiently, or may simply free CPU time for other tasks. In either case, the overall performance of the computer system may be increased.

Since the CPU controls the coprocessor (detenrώiing when it will perform its operations, etc.), an interface between the CPU and the coprocessor is needed. It is desirable that this interface be efficient, so that the CPU can rapidly activate the coprocessor and/or determine the result of the operation and acquire the result for use in other processing activities.

An additional complication in interfacing the CPU and the coprocessor, over and above providing an efficient interface, arises in computer systems which support multitasking. In multitasking, the computer system may allow concurrent operation of one or more processes. Each process may be allocated CPU time to execute, interleaved with CPU time for other processes. As used herein, a process is a code sequence which is executed independent of other processes. Two processes executing concurrently on the same CPU may have no relationship to each other. The process state (register values as well as memory location values) is maintained by the CPU separate from the process state belonging to other processes (although in some cases there may be interprocess communication through one or more memory locations).

The problem that arises for interfacing to a coprocessor in a multitasking environment is in managing use of the coprocessor by multiple processes. A first process may be executing, and may require use of the coprocessor. Thus, the CPU may initiate an operation on the coprocessor for the first process. Subsequently, before the CPU determines that the operation is complete and receives the output of the operation (if any) for the first process, the CPU may begin executing a second process. If the second process also requires use of the coprocessor, contention for the coprocessor may occur. Thus, an interface to the coprocessor which is efficient and which also eases the problem of managing contention among multiple processes for the coprocessor is therefore desired. SUMMARY OF THE INVENTION

The problems outlined above are in large part solved by a coprocessor having a service port architecture as described herein. The coprocessor may support multiple service ports, each of which may be assigned to a different process. Operations supported by the coprocessor may be requested using commands to the service port, and status may be checked using status commands to the service port. Since different processes may be assigned to different service ports, the coprocessor may be able to determine, while performing an operation for a process, that a different process is requesting an operation. More particularly, a command to a different service port may be received. In one embodiment, the coprocessor may interrupt the in-progress operation to perform the newly requested operation. When status is requested for the interrupted operation, the coprocessor may return a failure status code indicating the operation was interrupted. The process corresponding to the interrupted operation may then reattempt the interrupted operation, or may handle the operation by a different mechanism (e.g. software assistance). Advantageously, process switching may be unconcerned about the status of the coprocessor. Instead, the coprocessor may handle contention for coprocessor resources. Additionally, in cases in which a process is switched out while a coprocessor operation is being performed and switched back in before any contention for the coprocessor is detected, the coprocessor may continue operation while the process is switched out. Performance of the system as a whole may be improved.

In one embodiment, the coprocessor may manage the interruption of operations using a reservation scheme. When the coprocessor initiates an operation for a service port (in response to a command on the service port), the coprocessor establishes a reservation for that service port. The reservation may indicate that an operation from the service port is in progress or has been completed and no other service port has requested an operation. If a command is received on a different service port and the coprocessor interrupts the in-progress operation, the reservation for the service port corresponding to the in-progress operation may be cancelled. Thus, if a reservation for a service port is inactive when a status command is received on that service port, then the coprocessor may indicate that the operation failed (was unsuccessful) due to interruption by another operation from a different service port.

In one embodiment, the coprocessor may support the locking of one or more resources which may store the output of an operation. Once an operation has been successfully completed, the resources may be locked to prevent use of the resources until the process which requested the operation is done with the resources. If another operation would use the resources locked to a service port, that operation may be terminated with a failure status indicating that the resources used are locked to another service port.

The service port architecture may also be an efficient interface to the coprocessor. An operation may be initiated using a command to a service port (e.g. a store instruction to a predefined address comprising the service port). An operation's status may be checked using a status command to a service port (e.g. a load instruction to the predefined address).

Broadly speaking, a system is contemplated comprising a central processing unit (CPU) and a coprocessor. The CPU is configured to execute an instruction to generate a predefined address. Coupled to receive the predefined address and an indication of a type of the instruction, the coprocessor is configured to perform a predefined operation in response to the predefined address and the type of the instruction.

Additionally, a coprocessor is contemplated comprising an external interface unit and a control circuit. The external interface unit is coupled to receive, in response to execution of an instruction in a CPU, a predefined address and an indication of a type of the instruction. Coupled to receive an indication of the predefined address and the type of instruction from the external interface unit, the control circuit is configured to initiate a predefined operation in the coprocessor in response to the predefined address and the type of the instruction.

Furthermore, a method is contemplated. A predefined address and an indication of a type of instruction executed is received in a coprocessor. A predefined operation is performed in the coprocessor responsive to the predefined address and the type of instruction.

Still further, another method is contemplated. A first service port of a coprocessor is assigned to a first process. A second service port of the coprocessor is assigned to a second process. A command to initiate an operation is received in the coprocessor. The operation is associated with the first process if the command is received to the first service port, and the operation is associated with the second process if the command is received to the second service port.

Moreover, a system is contemplated comprising a CPU and a coprocessor. The CPU is configured to generate a command to a first service port of a coprocessor, the first service port being one of a plurality of service ports supported by the coprocessor. The first service port is assigned to a first process being executed by the CPU. Coupled to receive the command to the first service port, the coprocessor is configured to initiate a first operation responsive to the command.

Additionally, a coprocessor is contemplated comprising an external interface and a control circuit. The external interface unit is coupled to receive a command from a CPU to a first service port of a plurality of service ports supported by the coprocessor. The first service port is assigned to a first process being executed by the CPU. Coupled to receive an indication of the command and the first service port from the external interface unit, the control circuit is configured to initiate a first operation in response to the command.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects and advantages of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings in which:

Fig. 1 is a block diagram of one embodiment of a computer system.

Fig. la is a block diagram of a second embodiment of a computer system.

Fig. 2 is a table illustrating addresses of one embodiment of service ports.

Fig. 3 is a table illustrating one embodiment of words within a service port.

Fig. 4 is a flowchart illustrating operation of one embodiment of a coprocessor for a service port write.

Fig. 5 is a flowchart illustrating operation of one embodiment of a coprocessor for processing a requested service.

Fig. 6 is a flowchart illustrating operation of one embodiment of a coprocessor for a service port read.

Fig. 7 is a flowchart illustrating operation of another embodiment of a coprocessor for a service port write.

Fig. 8 is a flowchart illustrating operation of another embodiment of a coprocessor for a service port read.

Fig. 9 is a block diagram of one embodiment of registers corresponding to a service port.

Fig. 10 is a block diagram of one embodiment of a lock register illustrated in Fig. 10.

Fig. 11 is an example of service port requests and reservations. Fig. 12 is a flowchart illustrating one embodiment of registration of a process with the coprocessor.

Fig. 13 is a flowchart illustrating one embodiment of unregistration of a process with the coprocessor.

Fig. 14 is a block diagram of one embodiment of a service port status register.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Turning now to Fig. 1, a block diagram of one embodiment of a system 10 is shown. Other embodiments are possible and contemplated. The illustrated system 10 includes a central processing unit (CPU) 12, a memory controller 14, a memory 16, a Peripheral Component Interconnect (PCI) bridge 18, a PCI bus 20, and a coprocessor 22. CPU 12 is coupled to PCI bridge 18 and memory controller 14. Memory controller 14 is further coupled to memory 16. PCI bridge 18 is further coupled to PCI bus 20. Coprocessor 22 is coupled to PCI bus 20. In the illustrated embodiment, coprocessor 22 includes an external interface unit 24 and a service port control circuit 26 (which includes a set of service port registers 28). In one embodiment, CPU 12, memory controller 14, and PCI bridge 18 may be integrated onto a single chip or into a package as illustrated by the dotted line surrounding these components in Fig. 1 (although other embodiments may provide these components separately).

Generally, CPU 12 is configured to activate coprocessor 22 when a process being executed on CPU 12 requires an operation performed by coprocessor 22. The operation or operations for which coprocessor 22 is designed may be varied from embodiment to embodiment. Examples of coprocessors may include math coprocessors designed to perform floating point computations, graphics coprocessors designed to handle graphics manipulations, digital signal processors designed to process signals measured external to the computer system, etc. In one particular embodiment, coprocessor 22 may be a code translator configured to translate non-native code sequences to native code sequences including native instructions executable by CPU 12. In one particular example, the non-native code sequences may be Java code sequences. Other examples may translate any other non-native code sequences (e.g. extended markup language (XML), structured query language (SQL), hypertext markup language (HTML), standard generalized markup language (SGML), etc.). Other embodiments may translate other code sequences. While the code translator example may be used at certain points in this description, any coprocessor may benefit from the efficient coprocessor interface provided by the service port architecture described in more detail below.

Coprocessor 22 provides an efficient interface for CPU 12 to communicate with coprocessor 22 via the service port architecture. Each process executing on CPU 12 which may use coprocessor 22 is assigned a different service port. As used herein, a service port is a group of one or more addresses to which CPU 12 may transmit commands. Transmitting a command to a service port may comprise executing an instruction which generates one of the addresses corresponding to the service port (e.g. a store instruction or a load instruction). Execution of the instruction may cause CPU 12 to transmit the address to memory controller 14 and PCI bridge 18, which may route the address to coprocessor 22. Additionally, the type of instruction (load or store) is communicated as a read or write operation from CPU 12 to PCI bridge 18 and by PCI bridge 18 on PCI bus 20. Thus, coprocessor 22 receives an indication of the type of instruction executed. Based on the address and the type of instruction, coprocessor 22 may perform one of the one or more operations for which coprocessor 22 is designed. The data corresponding to the instruction may be used as an operand of the selected operation, as described in more detail below.

Since different processes are assigned to different service ports, coprocessor 22 may associate the operation being performed with a particular process. Rather than replicate the hardware used for an operation so that multiple service ports may concurrently perform the operation, coprocessor 22 may share such hardware among the service ports. The sharing of hardware may be possible since only one process may be actively executing on CPU 12 at any given point in time. The sharing of hardware may lead to circuit area savings. Since the hardware may be shared, if a command is received to another service port than the service port corresponding to the currently executing operation, coprocessor 22 may interrupt the currently executing operation and begin executing the newly requested operation. Since the newly requested operation corresponds to a process currently executing on CPU 12, it may be desirable to perform the newly requested operation instead.

Coprocessor 22 may provide for a status command as well as a command to cause an operation to occur. The status command may allow the process to determine when a requested operation has completed. Additionally, the status command may allow coprocessor 22 to communicate the interruption of the operation. Thus, the interface to coprocessor 22 for operations which may be interrupted may include a paired command (to initiate the operation) and status command (to determine if the operation was successful). The operation may be unsuccessful if interrupted by another process, or for other reasons specific to the operation (as will be explained in more detail below). In one particular embodiment, a store to a service port may be a command to initiate an operation and a load to the service port may be a status command to determine the status of the operation. Thus, the interface to coprocessor 22 for most operations may be a store to the service port assigned to the process followed by a load to the service port to determine status (although a code sequence may include as many other instructions as desired between the store and the corresponding load). If CPU 12 switches to another process between the store and the subsequent load and the other process uses coprocessor 22, the load corresponding to the interrupted process will receive a failure status and the requested operation may be performed again. While stores are used as commands in the present embodiment, loads may be used in alternative embodiments.

Coprocessor 22 is able to determine that different processes are requesting operations via the different service ports on which the commands are received. Coprocessor 22 tracks which requested operation is proceeding without interruption, and interrupts an operation when a request on a different service port is received. Thus, process switches on CPU 12 may be performed without regard to whether coprocessor 22 is performing an operation for the process currently executing on CPU 12. If the process switched to requests an operation of coprocessor 22, coprocessor 22 interrupts the currently executing operation. The status command executed by the process corresponding to the interrupted operation receives a failure status, and the process may take corrective action (e.g. reattempting the operation) in response to the status. Process management in system 10 may thereby be simplified. In one embodiment, coprocessor 22 establishes a reservation for a service port in response to a command to initiate an operation. The reservation indicates that an operation corresponding to that service port is being performed or has been performed by coprocessor 22 and that no process corresponding to a different service port has requested an operation from coprocessor 22 since the command to initiate the operation has been received. If a command is received on another service port, the reservation is cancelled (and established for the other service port for which the command to initiate the operation has been received). Coprocessor 22 checks the reservation on a particular service port when a status command is received, and returns a failure status if the reservation is not active for that particular service port.

After an operation has been successfully completed (via a successful status command), it is possible that one or more resources storing an output of the operation may be required by the process. In other words, the process may not be ready to release the resources for use by operations belonging to other processes. Coprocessor 22 may provide for locking of such resources to a service port (and thus to the corresponding process). If an operation for another service port (and thus another process) uses the locked resources, that operation may be terminated by coprocessor 22 with a failure status. In other words, if a resource is locked to a service port, other service ports are prevented from using the resource. For example, in various embodiments, successful completion or initiation of an operation via a status command may cause coprocessor 22 to lock resources storing an output of the operation. The resources may remain locked, for example, until a subsequent operation is performed on the service port, an operation fails on the service port, or until the process releases the service port. Alternatively, coprocessor 22 may support a command to release the lock.

Since the command being performed to the service port indicates the operation to be performed, coprocessor 22 initiates a requested operation dependent of any data corresponding to the command. For example, if a store to an address within the service port is a command, data is transmitted by CPU 12 in addition to the address. The data does not affect which of the one or more operations is to be performed by coprocessor 22, since the address specifies the operation. Instead, the data may be used as an operand to the operation. Similarly, a load to an address within the service port specifies the operation for which status is desired. The data returned in response to the load may be the status, and may additionally provide other information about the operation (e.g. the output of the operation, an address of a memory location(s) storing the output of the operation, etc.). Thus, the interface to coprocessor 22 may be fairly efficient since an operation may be initiated using a store instruction (and perhaps one or more instructions to generate the operand for the operation as the store data) and completion of the operation may be provided using a load instruction (and perhaps one or more instructions to analyze the status provided).

The addresses comprising a service port may exceed the data size operated upon by a load or a store. The data size may be referred to herein as a "word". A different word may be used for each of the operations supported by coprocessor 22. For example, if coprocessor 22 provides 4 different operations, each service port may include 4 words. A command to the first word in the service port initiates the first operation supported by coprocessor 22, a command to the second word in the service port initiates the second operation supported by coprocessor 22, etc. It is noted that many CPU architectures support multiple data sizes. The word size for the service ports may be selected to be the most common data size in the CPU architecture, or the data size for which the CPU architecture is optimized. Alternatively, the word size may be any convenient size.

. In the illustrated embodiment, coprocessor 22 may include external interface unit 24 coupled to service port control circuit 26. Generally, external interface unit 24 provides an interface between internal circuitry of coprocessor 22 (including service port control circuit 26 and other circuitry, not shown, for performing the operations for which coprocessor 22 is designed) and the external interface to which coprocessor 22 is coupled. If external interface unit 24 receives a command to a service port, external interface unit 24 provides an indication of the command to service port control circuit 26. More particularly, in the present embodiment, external interface unit 24 may receive a read or write transaction to a predefined address associated with a service port. External interface unit 24 may decode the address to determine that the transaction is a service port command, and may convey the address (or an indication of the corresponding service port and word within the service port) and the read/write nature of the transaction (which may be an indication of the type of instruction executed in CPU 12 to generate the transaction) to service port control circuit 26. Additionally, if the transaction is a write, external interface unit 24 may provide the data received with the write to service port control circuit 26. If the transaction is a read, service port control circuit 26 provides external interface unit 24 with the data to be transmitted in response to the read transaction.

In the illustrated embodiment, service port control circuit 26 includes service port registers 28. Service port registers 28 may include one or more registers per service port. The addresses comprising the service port may be mapped to the one or more registers assigned to that service port. Data received with a write may be stored into the register mapped to that address, and data from the register mapped to that address may be provided for a read. Other embodiments may not include service port registers 28.

Generally, CPU 12 executes native code sequences and controls other portions of the system in response to the native code sequences. CPU 12 may execute the operating system code for system 10, as well as any native application code that may be included in system 10.

Memory controller 14 receives memory read and write operations from CPU 12 and PCI bridge 18 and performs these read and write operations to memory 16. It is noted that some of the read and write operations presented by PCI bridge 18 may be read and write operations generated by coprocessor 22. Memory 16 may comprise any suitable type of memory, including SRAM, DRAM, SDRAM, RDRAM, or any other type of memory.

PCI bridge 18 facilitates communication between PCI bus 20 and memory controller 14 or CPU 12. More particularly, service port registers 28 may be memory-mapped registers. PCI bridge 18 may detect read or write operations to the addresses to which the registers are mapped, and transmit those operations on PCI bus 20 to coprocessor 22. As mentioned above, PCI bridge 18 may also detect read and write operations from coprocessor 22 to memory 16 on PCI bus 20 and may transmit those operations to memory controller 14.

It is noted that, while the PCI bus is used as an exemplary peripheral bus in the embodiment of Fig. 1, any other bus may be used. For example, the Universal Serial Bus (USB), IEEE 1394 bus, the Industry Standard Architecture (ISA) or Enhanced ISA (EISA) bus, the Personal Computer Memory Card International Association (PCMCIA) bus, etc. may be used. Still further, the Advanced RISC Machines (ARM) Advanced Microcontroller Bus Architecture (AMBA) bus, including the Advanced High-Performance (AHB) and/or Advanced System Bus (ASB) may be used, as may the Handspring Interconnect specified by Handspring, Inc. (Mountain View, CA). Still further, coprocessor 22 may be connected to memory 16 using a Unified Memory Architecture connection (e.g. see Fig. 1A). The bus used for the Unified Memory Architecture connection may be any of the above buses. In other alternatives, coprocessor 22 may be directly connected to CPU 12 or memory 16, or may be integrated into CPU 12, memory controller 14, or PCI bridge 18.

As mentioned above, one embodiment of coprocessor 22 is a code translator. Additional details regarding such an embodiment are now provided. Generally, CPU 12 is capable of executing instructions defined in a first instruction set (the native instruction set of system 10). The native instruction set may be any instruction set, e.g. the ARM instruction set, the PowerPC instruction set, the x86 instruction set, the Alpha instruction set, etc. Coprocessor 22 is provided for translating code sequences coded using a second instruction set, different from the native instruction set, to a code sequence coded using the native instruction set. Instruction sequences coded using the second instruction set are referred to as "non-native" code sequences, and code sequences coded using the first instruction set of CPU 12 are referred to as "native" code sequences.

When CPU 12 detects that a non-native code sequence is to be executed, CPU 12 executes a command to the service port corresponding to the currently executing process. The data corresponding to the store command may be the source address of the non-native code sequence. In response to the command, coprocessor 22 reads the non-native code sequence from the source address, translates the non-native code sequence to a native code sequence, and stores the native code sequence at a target address. Subsequently, CPU 12 may transmit a status command to the service port. Coprocessor 22 provides the status in response to the status command. The status may include a success/failure indication and may further include the target address at which the translated native code sequence is stored. For successfully translated code sequences, the CPU 12 may proceed to execute the translated code sequence from the target address.

In one embodiment, coprocessor 22 is configured to translate Java code sequences to the native instruction set. The Java instruction set uses a stack-based programming and storage model, while the native instruction set may use a register-based prograrrrrning and storage model. As used herein, the term "stack-based programming and storage model" or "stack-based instruction set" refer to a model or instruction set in which operands for instructions are stored in a stack, generally in memory. Thus, execution of an instruction typically involves a memory reference for the operands (except for immediate operands). On the other hand, the terms "register-based programming and storage model" or "register-based instruction set" refer to a model or instruction set in which operands for instructions are stored in a set of registers defined by the architecture. Each register is identified via a register index, and the register indexes are coded into the instructions to specify the operands of the instructions. Operand fetch for instructions in a register-based instruction set are then generally reads of the registers, typically implemented within the CPU. Register-based instruction sets often use explicit load/store instructions to load operands from memory locations to registers for subsequent instructions to use as operands and to store results from registers to memory locations. Furthermore, the term "instruction set" as used herein refers to a group of instructions defined by a particular architecture. Each instruction in the instruction set may be assigned an opcode which differentiates the instruction from other instructions in the instruction set, and the operands and behavior of the instruction are defined by the instruction set. Thus, Java bytecodes are instructions within the instruction set specified by the Java language specification, and the term bytecode and instruction will be used interchangeably herein when discussing Java bytecodes. Similarly, ARM instructions are instructions specified in the ARM instruction set, PowerPC instructions are instructions specified in the PowerPC instruction set, etc.

Since coprocessor 22 may translate from a stack-based instruction set to a register-based instruction set, coprocessor 22 may include hardware for translating the stack references in the stack-based instruction set to register indexes in the register-based instruction set. More particularly, a subset (or "pool") of the registers may be reserved to store stack operands. Coprocessor 22 may assign register indexes as values are pushed onto the stack, and may use those register indexes as source operands for instructions which reference the stack. After the values are popped from the stack, the corresponding registers may be free for use for another value pushed onto the stack. Thus, the register pool may store the topmost operands on the stack, and memory may be used for lower items (as will be described in more detail below). The register-based instruction set may be most efficient at accessing operands in registers (since loads and stores may be needed to read the values from memory), and thus keeping items at the top of the stack in registers may enhance performance.

As an alternative to reserving the pool of registers, coprocessor 22 may be configured to statically or dynamically allocate registers from the register set of CPU 12 into the register pool. Coprocessor 22 may generate native instructions to store the registers selected for the pool to a scratchpad memory area (preserving the values in the selected registers), and then these registers may be used to store stack items. In a static embodiment, the entire pool of registers may be allocated at the beginning of a translated code sequence. In a dynamic embodiment, registers may be allocated to the pool as additional registers are needed during the translation. At the end of the translated code sequence, coprocessor 22 may insert instructions to restore the values of these registers by reading the values from the scratchpad memory area (after storing the items to the operand stack).

In one embodiment, coprocessor 22 may translate instructions beginning at the source address and up to a basic block boundary in response to being activated by CPU 12. Generally, instructions within a basic block are not branch instructions (e.g. conditional or unconditional branches, call or return instructions, etc.). Once a basic block is entered, each instruction in the basic block is executed. The basic block boundary is formed by an branch instruction. Other embodiments may employ branch prediction and speculatively translate instructions past the basic block boundary based on the branch prediction. If the branch prediction is incorrect, the speculative translation may be discarded.

In another embodiment, coprocessor 22 may translate instructions through an unconditional branch, stopping translation when a conditional branch instruction or the end of the code sequence is encountered. The unconditional branch instruction may be deleted from the translated code sequence ("folded out") and the instructions at the target address of the unconditional branch instruction may be inserted in-line in the translated code (sequential to the instructions translated from the code preceding the unconditional branch instruction). Such an embodiment may further provide speculative translation beyond conditional branches, as mentioned above. Still further, coprocessor 22 may fold out "redundant" stack operations (e.g. instructions which push the same value back onto the same stack storage location due to earlier instructions having popped the value from that stack storage location). Additionally, coprocessor 22 may limit the total number of instructions translated before stopping. The total number may be the number of source instructions (e.g. non-native instructions) or the number of target instructions (e.g. native instructions). Alternatively, the number of bytes may be limited (and may be either the number of bytes of source instructions or the number or bytes of target instructions). The limit on the number of bytes/instructions may be programmable in a configuration register of coprocessor 22 (not shown). In one particular implementation, for example, a maximum size of 64 or 128 bytes of translated code may be programmably selected.

Turning now to Fig. 2, a table 30 is shown illustrating exemplary addresses assigned to service ports according to one embodiment of coprocessor 22. Other embodiments are possible and contemplated. The addresses illustrated in Fig. 2 are exemplary only, and any set of addresses may be used. The addresses listed in table 30 are actually offsets from a base address. The base address may be predefined and may vary from implementation to implementation. Alternatively, the base address may be programmable in a memory mapped register within coprocessor 22 (not shown).

Each offset illustrated in Fig. 2 is associated with a different service port number (e.g. 0-15 in the illustrated embodiment for a total of 16 service ports). Thus, the embodiment shown may support up to 16 processes which may require use of coprocessor 22.

In the embodiment shown, the difference in offsets between service ports is 16 bytes. Thus, each service port includes 16 bytes of address space which may be used for commands. In one particular embodiment, the 16 bytes may be divided in to four 4 byte words. Each word may be used for a different operation supported by coprocessor 22. Thus, in the illustrated embodiment, up to four different operations may be supported using a store/load pair per operation. Additional operations may be supported by making the difference in offsets to different service ports larger, or by making the word size smaller. In an embodiment using only a single command per operation, up to 8 different operations may be supported with four 4 byte words (one operation per word for loads and one operation per word for stores). Additionally, various embodiments may use a store/load pair for some operations and a single command for others (e.g. Fig. 3 below).

Fig. 3 is a table 32 illustrating one embodiment of the words of a service port and the corresponding operations supported. Other embodiments are possible and contemplated. The embodiment shown in Fig. 3 may correspond to a code translator embodiment of coprocessor 22.

As table 32 illustrates, word 0 of a service port is used to request a translation operation, word 1 is used to perform a lookup operation, and word 3 is used for reservation operations. Word 2 is reserved in the illustrated embodiment.

A process requests a translation of a code sequence by performing a command to word 0 (e.g. executing a store instruction, resulting in a write to word 0) of the service port assigned to that process. The store data may be the address in memory 16 of the first instruction of the code sequence to be translated. The process may check the status of the translation by performing a status command to word 0 (e.g. executing a load instruction, resulting in a read to word 0) of the service port assigned to the process. The status returned may comprise a failure status (including a code as to the reason the translation was unsuccessful) or may comprise the address of the first instruction of the translated code sequence, if the translation was successful. In one embodiment, coprocessor 22 is allocated a block of memory to store translated code sequences. Coprocessor 22 may manage the memory as a cache, and may assign a cache location to the translated code sequence. The address returned is a pointer to the translated code sequence in memory.

Several failure status codes may be possible in the translation operation according to various embodiments of the coprocessor 22. Loss of the reservation for the service port may be one failure. Another failure may be that a source instruction which coprocessor 22 is not configured to translate was detected. Yet another failure code may be that coprocessor 22 ran out of resources (e.g. register indexes) and thus a service routine to allocate more register indexes is to be executed. Detection of an exception condition in the source code sequence may be a failure code, indicating that the source code sequence should be executed in interpreter mode to handle the exception. In one specific embodiment, the source address of the source code sequence may be a virtual address and coprocessor 22 may translate the address to a physical address. In such an embodiment, a failure code may indicate that translation failed for the source address.

A process may lookup a source address in the cache mentioned above to deteπrrine if the code sequence has already been translated and still resides in the translation cache. The process performs a command (e.g. a store instruction) to word 1 of its service port to request the lookup operation. The source address may be provided as the store data for the command. Subsequently, the process may perform a status command (e.g. a load instruction) to word 1 of its service port to receive status. If the lookup results in a hit, the returned status may be the address of the translated code sequence. If the lookup results in a miss, the returned status may be zero (a failure status for this operation). Another failure status may be that the reservation was lost by the service port between the lookup command and the lookup status command.

The reservation operations for word 3 may or may not be performed as a write/read (store/load) pair the way that other operations are performed as described above. For example, a process may check to see if its service port still has a reservation (the check reservation command) even if the process has not performed the set reservation command. Additionally, the process may perform a set reservation command and then proceed with another command (e.g. a translation request or a lookup request) without performing the check reservation command. Generally, the set reservation command is used to establish the reservation for the service port. The store data, in this case, may be a don't care. The check reservation command is used to determine if the service port still retains a reservation. The response to the check reservation command may indicate success if the reservation is set for the service port, or failure if the reservation is not maintained for the service port.

Figs. 4-6 illustrate a first embodiment of operation of coprocessor 22 in which resource locking (if employed) is performed at the initiation of an operation which may store output in the resource. Figs. 7-8 illustrate a second embodiment of operation of coprocessor 22 in which resource locking (if employed) is performed at the status command portion of an operation when the operation is successfully completed. Either embodiment may be used, and embodiments in which resource locking is not employed are contemplated as well. Furthermore, resource locking may be used for some operations supported by coprocessor 22 but not for others, as desired.

Turning now to Fig. 4, a flowchart is shown illustrating the operation of one embodiment of coprocessor 22 (and more particularly service port control circuit 26, in one embodiment of coprocessor 22) in response to a write (e.g. a store instruction) to a service port. Other embodiments are possible and contemplated. While the flowchart is shown in a particular order for ease of understanding, any suitable order may be used. Furthermore, circuitry performing the flowchart may perform various portions in parallel.

Coprocessor 22 determines if the reservation is active for the service port receiving the write (decision block 40). If the reservation is active, coprocessor 22 may set the lock status for the service port (block 42) to indicate locked, reserving any resources which may be used to store output of the requested operation for the service port. Additionally, coprocessor 22 begins processing the requested operation (block 44). Optionally, the requested operation may use the data provided by the service port write as an operand.

If the reservation is not active for the service port, coprocessor 22 determines if another service port has an active reservation (decision block 46). If another service port has an active reservation, its reservation is cancelled, along with any in-progress operation in coprocessor 22 (block 48). In either case, a reservation is established for the service port receiving the service port write (block 50). Additionally, coprocessor 22 may set the lock status for the service port (block 42) and begin processing the requested operation (block 44). Turning now to Fig. 5, a flowchart is shown illustrating the operation of one embodiment of coprocessor 22 (and more particularly service port control circuit 26, in one embodiment of coprocessor 22) while a requested operation is in progress. Other embodiments are possible and contemplated. While the flowchart is shown in a particular order for ease of understanding, any suitable order may be used. Furthermore, circuitry performing the flowchart may perform various portions in parallel. It is noted that the flowchart of Fig. 5 represents operation for handling service port functions, and does not show the other operations coprocessor 22 may perform in carrying out the requested operation.

Coprocessor 22 determines if the operation requires use of a resource which is locked for another service port (decision block 52). If a locked resource is required, coprocessor 22 terminates the operation and records a failure status code for the service port (and requested operation within the service port) for later transmission in response to a status command on that service port (block 54). It is noted that the blocks 52 and 54 (as a result of block 52) may alternatively be performed upon receiving the service port write which initiates the operation.

In one embodiment, a resource which may be locked for the translation operation is the cache location storing the translated code sequence. Thus, for example, a translation operation may require a locked resource if all the cache locations eligible for storing the translated code sequence are locked for other service ports.

If coprocessor 22 determines that the operation does not require use of a locked resource, coprocessor 22 determines if the operation results in a failure (decision block 56). If a failure is detected, coprocessor 22 may terminate the operation and record a failure status code for the service port (and requested operation within the service port) for later transmission in response to a status command on that service port (block 54).

Turning next to Fig. 6, a flowchart is shown illustrating the operation of one embodiment of coprocessor 22 (and more particularly service port control circuit 26, in one embodiment of coprocessor 22) in response to a service port read. Other embodiments are possible and contemplated. While the flowchart is shown in a particular order for ease of understanding, any suitable order may be used. Furthermore, circuitry performing the flowchart may perform various portions in parallel.

Coprocessor 22 determines if a reservation remains active for the service port (decision block 60). If the reservation is not active, coprocessor 22 provides a failure status as the response to the status command (block 62). The status code may indicate that the operation failed due to loss of reservation, rather than other reasons that the operation may fail. Additionally, coprocessor 22 may clear the lock status for the service port, thereby freeing any resources locked for the service port. Since the operation failed, there may be no output to be stored in the locked resource.

If the reservation is still active, coprocessor 22 determines if the operation corresponding to the status command is complete (decision block 64). If the operation is not complete, coprocessor 22 may perform one of two actions, depending on the embodiment: provide a busy response status to the status command, or retry the status command (block 66). A retry of the status command may be performed by external interface unit 24 on the external interface to which coprocessor 22 is coupled. The retry causes CPU 12 (or bus bridge 18) to reattempt the read operation comprising the status command until it is not retried. When no retry occurs, the data transferred is provided as the result of the load instruction. In an embodiment in which a busy status is provided, the process generating the status command may reexecute the load instruction until a non-busy status (successful or failure) is provided by coprocessor 22. In yet another alternative, coprocessor 22 may be designed to progress through a requested operation to certain stopping points, at which time the operation stalls until a read of the service port is provided. The busy status may be returned in response to the read, and coprocessor 22 may proceed to the next step in the operation. Such an embodiment may provide a process with a finer granularity of control over coprocessor 22.

If the requested operation is complete, coprocessor 22 may provide a successful status (or failure status with a code indicating the failure, if the operation terminates in a failure) (block 68). Optionally, the successful status may also provide result data (e.g. the address at which the translated code sequence is stored, for words 0 and 1 of the service port illustrated in Fig. 3). If the operation failed (decision block 72), coprocessor 22 may clear the lock status for the service port (block 74).

The description of a second embodiment of coprocessor 22 is next provided (illustrated in Figs. 7-8). In Figs. 7-8, the same reference numerals used in Figs. 4-6 are used for blocks which are similar. Fig. 7 illustrates the handling of a service port write, and Fig. 8 illustrates the handling of a service port read. It is noted that coprocessor 22 may handle the processing of the operation initiated by the service port write in a manner similar to Fig. 5

Turning now to Fig. 7, a flowchart is shown illustrating the operation of a second embodiment of coprocessor 22 (and more particularly service port control circuit 26, in one embodiment of coprocessor 22) in response to a write (e.g. a store instruction) to a service port. Other embodiments are possible and contemplated. While the flowchart is shown in a particular order for ease of understanding, any suitable order may be used. Furthermore, circuitry performing the flowchart may perform various portions in parallel.

Coprocessor 22 determines if the reservation is active for the service port receiving the write (decision block 40). If the reservation is active, coprocessor 22 may clear the lock status for the service port (block 58), freeing any resources which may have been locked for the service port. Since the process is starting another operation on coprocessor 22, it is assumed that the process is finished with the locked resources. Additionally, coprocessor 22 begins processing the requested operation (block 44). Optionally, the requested operation may use the data provided by the service port write as an operand.

If the reservation is not active for the service port, coprocessor 22 determines if another service port has an active reservation (decision block 46). If another service port has an active reservation, its reservation is cancelled, along with any in-progress operation in coprocessor 22 (block 48). In either case, a reservation is established for the service port receiving the service port write (block 50). Additionally, coprocessor 22 may clear the lock status for the service port (block 42) and begin processing the requested operation (block 44).

Turning next to Fig. 8, a flowchart is shown illustrating the operation of one embodiment of coprocessor 22 (and more particularly service port control circuit 26, in one embodiment of coprocessor 22) in response to a service port read. Other embodiments are possible and contemplated. While the flowchart is shown in a particular order for ease of understanding, any suitable order may be used. Furthermore, circuitry performing the flowchart may perform various portions in parallel.

Coprocessor 22 determines if a reservation remains active for the service port (decision block 60). If the reservation is not active, coprocessor 22 provides a failure status as the response to the status command (block 76). The status code may indicate that the operation failed due to loss of reservation, rather than other reasons that the operation may fail. As opposed to the embodiment illustrated in Fig. 6, block 76 does not include a modification of the lock status since the lock status is not set, in the embodiment of Fig. 8, until successful completion of the operation.

If the reservation is still active, coprocessor 22 determines if the operation corresponding to the status command is complete (decision block 64). If the operation is not complete, coprocessor 22 may perform one of two actions, depending on the embodiment: provide a busy response status to the status command, or retry the status command (block 66). A retry of the status command may be performed by external interface unit 24 on the external interface to which coprocessor 22 is coupled. The retry causes CPU 12 (or bus bridge 18 or external interface unit 24) to reattempt the read operation comprising the status command until it is not retried. When no retry occurs, the data transferred is provided as the result of the load instruction. In an embodiment in which a busy status is provided, the process generating the status command may reexecute the load instruction until a non-busy status (successful or failure) is provided by coprocessor 22. In yet another alternative, coprocessor 22 may be designed to progress through a requested operation to certain stopping points, at which time the operation stalls until a read of the service port is provided. The busy status may be returned in response to the read, and coprocessor 22 may proceed to the next step in the operation. Such an embodiment may provide a process with a finer granularity of control over coprocessor 22.

If the requested operation is complete, coprocessor 22 may provide a successful status (or failure status with a code indicating the failure, if the operation terminates in a failure) (block 68). Optionally, the successful status may also provide result data (e.g. the address at which the translated code sequence is stored, for words 0 and 1 of the service port illustrated in Fig. 3). Additionally, if the requested operation leaves output in a resource which may be shared with operations initiated from other service ports, those resources may optionally be locked for the service port (block 70). It is noted that the resources may not be locked, in one embodiment, if the requested operation does not complete successfully.

Turning now to Fig. 9, a block diagram of one embodiment of service port registers 28A (part of service port registers 28) is shown. Other embodiments are possible and contemplated. Service port registers 28A may be the registers mapped to service port 0. Other service ports may include a similar set of registers mapped to that service port. In the embodiment shown, service port registers 28A include a word 0 register 28AA, a word 1 register 28AB, a word 2 register 28AC, a word 3 register 28AD, a reservation register 28AE, and a lock register 28AF.

Word registers 28AA-28AD correspond to each of the words to which commands may be addressed. Word registers 28AA-28AD may receive data corresponding to a write to the corresponding word, and may be used to temporarily store status information to be provided in response to a read of the corresponding word. It is noted that, for the embodiment of Fig. 3, word 2 register 28AC may be eliminated since a command to word 2 of the status port is undefined (or reserved).

Reservation register 28AE may store the reservation status for service port 0. The reservation may, for example, be represented by a bit. If the bit is set, the reservation may be active, and if the bit is not set, the reservation may be inactive (or cancelled). Alternatively, if the bit is not set, the reservation may be active, and if the bit is set, the reservation may be inactive. Other embodiments are possible as well. Furthermore, while reservations are maintained on a service port basis in the present embodiment, other embodiments are contemplated in which the reservations are maintained on a service port and operation basis (e.g. a different reservation may be maintained for each operation which may be requested via a service port). In such an embodiment, different processes could request different operations without interfering with each other's use of coprocessor 22. Still further, reservation register 28AE could be eliminated in favor of a single reservation register that indicates which service port has an active reservation. Reservation status may be determined by comparing the service port recorded in the reservation register with the service port for which reservation status is desired.

Lock register 28AF may be used to store an indication of resources which are locked for this service port. The lock register may also include a lock indication, indicating whether or not a lock is maintained for the service port. If the lock indication indicates that the resource is locked, then coprocessor 22 prevent access to or modification of the resource by operations corresponding to other service ports.

An exemplary lock register 28AF for one embodiment of coprocessor 22 as a code translator is illustrated in Fig. 10. For the illustrated embodiment, the cache location storing the translated code sequence corresponding to a translation operation from the service port is a resource which may be locked. Accordingly, the indication of the resource may be an index (a portion of the source address of the source code sequence which was translated) and a way (for set associative caching structures). Additionally, the lock indication (L) is included (and may be a bit indicative of lock when set and no lock when clear, or vice versa). Thus, an exemplary condition in which a locked resource is used by a first operation is the first operation being a translation, and the source address of the translation having an index for which all ways are locked (unless one of the ways is locked for the service port corresponding to the first operation, in which case that way may be used by the first operation).

Turning now to Fig. 11, an example of two processes (process A and process B) which may use coprocessor 22 is shown. In the example, process A is executing and performs a store to service port A (the service port assigned to process A) (reference numeral 80). The store is a command to initiate an operation on coprocessor 22, and establishes a reservation for service port A in coprocessor 22. Coprocessor 22 may begin processing the requested operation for service port A. Subsequently, the operating system in system 10 performs a process switch to process B (reference numeral 82). Process B performs a store to service port B (the service port assigned to process B) to initiate an operation in coprocessor 22 for process B (reference numeral 84). The store to service port B interrupts the operation for service port A and clears the reservation for service port A. Also, coprocessor 22 establishes the reservation for service port B and begins processing the requested operation for service port B. Process B then executes a load to service port B (reference numeral 86) to determine the status of the requested operation (although other instructions may intervene). The status is returned as successful. Subsequently, the operating system performs a process switch back to process A (reference numeral 88). Process A performs a load to status port A, and receives an unsuccessful (or failure) status due to reservation loss (reference numeral 90). Process A may reinitiate the operation using store 80, if desired.

As Fig. 11 illustrates, the process switching code may not be required to determine whether or not coprocessor 22 is operating for a process that is being switched out. Instead, coprocessor 22 detects the contention for coprocessor operation via the different service ports used, and provides an indication to the interrupted process that the operation has been interrupted. The interrupt process may restart the operation. Additionally, if a process switch occurs and the process switched to does not use coprocessor 22, coprocessor 22 may continue performing the operation of the interrupted process. When the interrupted process is resumed, it may still have an active reservation in coprocessor 22 and may thus retain the result of the operation (which may have been completed while another process was executing in CPU 12).

Turning now to Fig. 12, a flowchart illustrating the registration of a process with coprocessor 22 (to be allocated a service port) is shown. Other embodiments are possible and contemplated. While the flowchart is shown in a particular order for ease of understanding, any suitable order may be used. Furthermore, circuitry performing the flowchart may perform various portions in parallel. It is noted that a portion or all of the registration of a process may be performed partially in software (e.g. firmware provided with coprocessor 22).

In response to receiving a registration request from a process, coprocessor 22 checks to see if a service port is currently unassigned (decision block 100). If all service ports are currently assigned, then coprocessor 22 may decline the request for registration (block 102). The process may then be prevented from using coprocessor 22 until a service port becomes available.

If at least one service port is unassigned, coprocessor 22 selects one of the unassigned service ports for the registering process (block 104). Coprocessor 22 sets the status of the selected service port to assigned, to prevent assignment to a subsequent registering process (block 106). Finally, the service port number of the selected service port is returned to the registering process (block 108).

Turning to Fig. 13, a flowchart illustrating the unregistration of a process with coprocessor 22 (to return an allocated service port to unallocated status) is shown. Other embodiments are possible and contemplated. While the flowchart is shown in a particular order for ease of understanding, any suitable order may be used. Furthermore, circuitry perfoπrring the flowchart may perform various portions in parallel. It is noted that a portion or all of the unregistration of a process may be performed in software (e.g. firmware provided with coprocessor 22). The unregistering process may provide the service port number currently assigned to that process.

Coprocessor 22 determines whether or not any locks are set for the unregistering process (decision block 110). If so, the lock is cleared since the process is unregistering (and thus will no longer have access to the service port) (block 112). In either case, coprocessor 22 sets the status of the selected service port to unassigned (block 114). In this manner, the service port becomes free for assignment to another process.

Fig. 14 illustrates one embodiment of a service port status register 120. Coprocessor 22 may include the service port status register 120, and may memory map the status register to an address so that CPU 12 may read and write the register. Service port status register 120 includes a field for each service port, in which the status of that service port may be recorded. The possible statuses include at least unassigned and assigned, and may be updated during the registration and unregistration of processes.

Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

WHAT IS CLAIMED IS:

1. A system comprising: a central processing unit (CPU) configured to execute an instruction to generate a predefined address; and a coprocessor coupled to receive said predefined address and an indication of a type of said instruction, wherein said coprocessor is configured to perform a predefined operation in response to said predefined address and said type of said instruction.

2. The system as recited in claim 1 wherein said instruction is a store instruction.

3. The system as recited in claim 2 wherein data provided via said store comprises an operand for said predefined operation.

4. The system as recited in claim 2 wherein said CPU is further configured to execute a load instruction to generate said predefined address, and wherein said coprocessor is configured to provide a status in response to said load instruction.

5. The system as recited in claim 1 wherein said instruction is a load instruction.

6. The system as recited in claύn 5 wherein data returned by said coprocessor in response to said load instruction is a status of said predefined operation.

7. The system as recited in claim 1 wherein said predefined operation is selected to be performed by said coprocessor independent of any data corresponding to said instruction.

8. A coprocessor comprising: an external interface unit coupled to receive, in response to execution of an instruction in a central processing unit (CPU), a predefined address and an indication of a type of said instruction; and a control circuit coupled to receive an indication of said predefined address and said type of instruction from said external interface unit, wherein said control circuit is configured to initiate a predefined operation in said coprocessor in response to said predefined address and said type of said instruction.

9. The coprocessor as recited in claim 8 wherein said control circuit further comprises one or more registers, wherein at least one of said one or more registers is mapped to said predefined address.

10. The coprocessor as recited in claim 9 wherein said instruction is a store instruction.

11. The coprocessor as recited in claim 10 wherein data provided via said store comprises an operand for said predefined operation, and wherein said data is stored into said at least one of said one or more registers.

12. The coprocessor as recited in claim 10 wherein said coprocessor is further coupled to receive said predefined address in response to a load instruction executed in said CPU to generate said predefined address, and wherein said coprocessor is configured to provide a status in response to said load instruction.

13. The coprocessor as recited in claim 8 wherein said instruction is a load instruction.

14. The coprocessor as recited in claim 13 wherein data returned by said coprocessor in response to said load instruction is a status of said predefined operation.

15. The coprocessor as recited in claim 8 wherein said control circuit is configured to initiate said predefined operation in said coprocessor independent of any data corresponding to said instruction.

16. A method comprising: receiving a predefined address and an indication of a type of instruction executed to generate said predefined address in a coprocessor; and performing a predefined operation in said coprocessor responsive to said predefined address and said type of instruction.

17. The method as recited in claim 16 wherein said instruction is a store instruction, and wherein said performing said predefined operation comprises using data provided in response to said store instruction as an operand of said predefined operation.

18. The method as recited in claim 17 further comprising: again receiving said predefined address, said again receiving including an indication of a load instruction executed to generate said predefined address, said again receiving into a coprocessor; and responding to said again receiving by providing a status of said predefined operation.

19. The method as recited in claim 16 wherein said instruction is a load instruction, and wherein said perfoπriing said predefined operation comprises returning a status of said predefined operation as data in response to said load instruction.

20. The method as recited in claim 16 wherein said performing said predefined operation is independent of any data corresponding to said instruction.