Processor with a coprocessor having early access to not-yet issued instructions

The present Application for Patent claims priority to Provisional Application No. 61/439,608 entitled “Processor with a Coprocessor having Early Access to Not-Yet Issued Instructions” filed Feb. 4, 2011, and assigned to the assignee hereof and hereby expressly incorporated by reference herein.

FIELD OF THE INVENTION

The present invention relates generally to techniques for organizing and managing an instruction queue in a processing system and, more specifically, to techniques for providing early access to not-yet issued instructions.

BACKGROUND OF THE INVENTION

Many products, such as cell phones, laptop computer, personal digital assistants (PDA), desktop computers, or the like, incorporate one or more processors executing programs that support communication and multimedia applications. The processors need to operate with high performance and efficiency to support the plurality of computationally intensive functions for such products.

The processors operate by fetching instructions from a unified instruction fetch queue which is generally coupled to an instruction cache. There is often a need to have a sufficiently large in-order unified instruction fetch queue supporting the processors to allow for the evaluation of the instructions for efficient dispatching. For example, in a system having two or more processors that share a unified instruction fetch queue, one of the processors may be a coprocessor. In such a system, it is often necessary to have a coprocessor instruction queue downstream from the unified instruction fetch queue. This downstream queue should be sufficiently large to minimize backpressure on processor instructions in the instruction fetch queue to reduce the effect of coprocessor instructions on the performance of the processor. Also, coprocessor instructions may require more processing stages to execute than the main processor. If there are instructions that require synchronization between the two processors, such a disparity in execution times can create performance bottlenecks. In addition, large instruction queues may be cost prohibitive in terms of power use, implementation area, and impact to timing and performance to provide the support needed for coprocessor instructions.

SUMMARY

Among its several aspects, the present invention recognizes a need for improved techniques for managing an instruction queue in a multiple processor system. To such ends, an embodiment of the invention applies a method for early access of instructions. A coprocessor instruction is copied from an instruction fetch queue, wherein the instruction fetch queue stores a mix of coprocessor instructions and processor instructions. Execution of the copied coprocessor instruction is started in the coprocessor before the coprocessor instruction is issued to a processor. The execution of the copied coprocessor instruction is completed based on information received from the processor after the coprocessor instruction has been issued to the processor.

Another embodiment of the invention addresses an apparatus for early access of instructions. A fetch queue is coupled to an instruction cache and configured to store a first class of instructions for a first processor and a second class of instructions for a second processor. A second class instruction selector is coupled to the fetch queue and configured to copy second class instructions from the fetch queue. A queue is coupled to the second class instruction selector and from which second class instructions are accessed for execution before the second class instruction is issued to the first processor.

Another embodiment of the invention addresses a method for starting execution of not-yet issued instructions. A plurality of coprocessor instructions is copied from an instruction fetch queue, wherein the instruction fetch queue stores a mix of coprocessor instructions and processor instructions in program order. Execution of the plurality of copied coprocessor instructions is started in the coprocessor before the plurality of coprocessor instructions are issued to a processor, wherein the execution of the plurality of copied coprocessor instructions is completed based on information generated by the processor in response to an evaluation of the plurality of coprocessor instructions issued to the processor.

Another embodiment of the invention addresses apparatus for early access of instructions. Means for storing a first class of instructions for a first processor and a second class of instructions for a second processor in a fetch queue coupled to an instruction cache. Means for copying second class instructions from the fetch queue. Means for accessing second class instructions for execution before the second class instruction is issued to the first processor.

Another embodiment of the invention addresses a computer readable non-transitory medium encoded with computer readable program data and code for operating a system. A coprocessor instruction is copied from an instruction fetch queue, wherein the instruction fetch queue stores a mix of coprocessor instructions and processor instructions. Execution of the copied coprocessor instruction is started in the coprocessor before the coprocessor instruction is issued to a processor. The execution of the copied coprocessor instruction is completed based on information received from the processor after the coprocessor instruction has been issued to the processor.

A more complete understanding of the present invention, as well as further features and advantages of the invention, will be apparent from the following Detailed Description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of an exemplary wireless communication system in which an embodiment of the invention may be advantageously employed;

<figref idref="DRAWINGS">FIG. 2A</figref> illustrates a processor complex with a memory hierarchy, processor, and a coprocessor in which an embodiment of the invention may be advantageously employed;

<figref idref="DRAWINGS">FIG. 2B</figref> illustrates exemplary coupling means between the processor and the coprocessor in which an embodiment of the invention may be advantageously employed;

<figref idref="DRAWINGS">FIG. 3A</figref> illustrates a process for providing early access to not-yet-issued instructions in which an embodiment of the invention may be advantageously employed;

<figref idref="DRAWINGS">FIG. 3B</figref> illustrates a process for communicating information between the coprocessor and the processor in which an embodiment of the invention may be advantageously employed;

<figref idref="DRAWINGS">FIG. 3C</figref> illustrates a process for updating coprocessor instructions within the coprocessor based on information generated in the processor in which an embodiment of the invention may be advantageously employed;

<figref idref="DRAWINGS">FIG. 3D</figref> illustrates a process for issuing coprocessor instructions in which an embodiment of the invention may be advantageously employed;

<figref idref="DRAWINGS">FIG. 3E</figref> illustrates a process for moving instructions from the in-order queue to the out-of-order queue in which an embodiment of the invention may be advantageously employed; and

<figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary embodiment of a coprocessor and processor interface in which an embodiment of the invention may be advantageously employed.

DETAILED DESCRIPTION

The present invention will now be described more fully with reference to the accompanying drawings, in which several embodiments of the invention are shown. This invention may, however, be embodied in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

Computer program code or “program code” for being operated upon or for carrying out operations according to the teachings of the invention may be initially written in a high level programming language such as C, C++, JAVA®, Smalltalk, JavaScript®, Visual Basic®, TSQL, Perl, or in various other programming languages. A program written in one of these languages is compiled to a target processor architecture by converting the high level program code into a native assembler program. Programs for the target processor architecture may also be written directly in the native assembler language. A native assembler program uses instruction mnemonic representations of machine level binary instructions specified in a native instruction format, such as a 32-bit native instruction format. Program code or computer readable medium as used herein refers to machine language code such as object code whose format is understandable by a processor.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary wireless communication system <b>100</b> in which an embodiment of the invention may be advantageously employed. For purposes of illustration, <figref idref="DRAWINGS">FIG. 1</figref> shows three remote units <b>120</b>, <b>130</b>, and <b>150</b> and two base stations <b>140</b>. It will be recognized that common wireless communication systems may have many more remote units and base stations. Remote units <b>120</b>, <b>130</b>, <b>150</b>, and base stations <b>140</b> which include hardware components, software components, or both as represented by components <b>125</b>A, <b>125</b>C, <b>125</b>B, and <b>125</b>D, respectively, have been adapted to embody the invention as discussed further below. <figref idref="DRAWINGS">FIG. 1</figref> shows forward link signals <b>180</b> from the base stations <b>140</b> to the remote units <b>120</b>, <b>130</b>, and <b>150</b> and reverse link signals <b>190</b> from the remote units <b>120</b>, <b>130</b>, and <b>150</b> to the base stations <b>140</b>.

In <figref idref="DRAWINGS">FIG. 1</figref>, remote unit <b>120</b> is shown as a mobile telephone, remote unit <b>130</b> is shown as a portable computer, and remote unit <b>150</b> is shown as a fixed location remote unit in a wireless local loop system. By way of example, the remote units may alternatively be cell phones, pagers, walkie talkies, handheld personal communication system (PCS) units, portable data units such as personal digital assistants, or fixed location data units such as meter reading equipment. Although <figref idref="DRAWINGS">FIG. 1</figref> illustrates remote units according to the teachings of the disclosure, the disclosure is not limited to these exemplary illustrated units. Embodiments of the invention may be suitably employed in any processor system having a two or more processors sharing an instruction queue.

In a system having two or more processors that share an instruction fetch queue, one of the processors may be a coprocessor, such as a vector processor, a single instruction multiple data (SIMD) processor, or the like. In such a system, an additional instruction queue may be utilized to minimize backpressure on processor instructions reducing the effect of coprocessor instructions in the instruction fetch queue on the performance of the processor. In order to improve on the performance of the coprocessor, the coprocessor is configured to process coprocessor instructions not having dependencies in an out-of-order sequence. Large queues may be cost prohibitive in terms of power use, implementation area, and impact to timing and performance to provide the support needed for tracking the program order of the instructions in the queue.

Queues may be implemented as in-order queues or out-of-order (OoO) queues. In-order instruction queues are basically first-in first-out (FIFO) queues that are configured to enforce a strict ordering of instructions. The first instructions that are stored in a FIFO queue are the first instructions that are read out, thereby tracking instructions in program order. Since many instructions that do not have dependencies can execute out of order, the strict FIFO order prevents executable out-of-order instructions from being executed. An out-of-order instruction queue, as used herein, is configured to write instructions in-order and to access instructions out-of-order. Such OoO instruction queues are more complex as they require an additional means of tracking program order and dependencies between instructions, since instructions in the queue may be accessed in a different order than they were entered. Also, the larger an OoO instruction queue becomes, the more expensive the tracking means becomes.

A processor complex instruction queue of the present invention consists of a combination of a processor instruction fetch queue and a coprocessor instruction queue. The processor instruction fetch queue is configured as a FIFO in-order instruction queue and stores a plurality of processor instructions and coprocessor instructions according to a program ordering of instructions. The coprocessor instruction queue is configured as a hybrid queue comprising an in-order FIFO queue and an out-of-order queue. The coprocessor instruction queue is coupled to the processor instruction fetch queue, from which coprocessor instructions are accessed out-of-order with respect to processor instructions and accessed in-order with respect to coprocessor instructions.

<figref idref="DRAWINGS">FIG. 2A</figref> illustrates a processor complex <b>200</b> with a memory hierarchy <b>202</b>, processor <b>204</b>, and a coprocessor <b>206</b>. The memory hierarchy <b>202</b> includes an instruction fetch queue <b>208</b>, a level 1 instruction cache (L1 I-cache) <b>210</b>, a predecoder <b>211</b>, a level 1 data cache (L1 D-cache) <b>212</b>, and a memory system <b>214</b>. While the instruction fetch queue <b>208</b> is shown in the memory hierarchy <b>202</b> it may also be suitably located in the processor <b>204</b> or in the coprocessor <b>206</b>. Instructions are written to the instruction fetch queue <b>208</b> in-order program order as fetched. Peripheral devices which may connect to the processor complex are not shown for clarity of discussion. The processor complex <b>200</b> may be suitably employed in hardware components <b>125</b>A-<b>125</b>D of <figref idref="DRAWINGS">FIG. 1</figref> for executing program code that is stored in the L1 I-cache <b>210</b>, utilizing data stored in the L1 D-cache <b>212</b> and associated with the memory system <b>214</b>, which may include higher levels of cache and main memory. The processor <b>204</b> may be a general purpose processor, a multi-threaded processor, a digital signal processor (DSP), an application specific processor (ASP) or the like. The coprocessor <b>206</b> may be a general purpose processor, a digital signal processor, a vector processor, a single instruction multiple data (SIMD) processor, an application specific coprocessor or the like. The various components of the processing complex <b>200</b> may be implemented using application specific integrated circuit (ASIC) technology, field programmable gate array (FPGA) technology, or other programmable logic, discrete gate or transistor logic, or any other available technology suitable for an intended application.

The processor <b>204</b> includes, for example, an issue and control circuit <b>216</b> having a program counter (PC) <b>217</b> and execution pipelines <b>218</b>. The issue and control circuit <b>216</b> fetches a packet of, for example, four instructions from the L1 I-cache <b>210</b> according to the program order of instructions and from the instruction fetch queue <b>208</b> for processing by the execution pipelines <b>218</b>. If an instruction fetch operation misses in the L1 I-cache <b>210</b>, the instruction is fetched from the memory system <b>214</b> which may include multiple levels of cache, such as a level 2 (L2) cache, and main memory. An instruction fetched from the memory system <b>214</b> is decoded in predecoder <b>211</b> which determines whether the fetch instruction is a coprocessor instruction. A fetched instruction identified as a coprocessor instruction is encoded with a short identifier, such as having all “1's” in three most significant bit positions in the encoded coprocessor instruction, for example. The encoded coprocessor instruction is then loaded in the instruction cache <b>210</b> and forwarded on bypass path <b>220</b> to a multiplexer function <b>219</b> for faster fetch response time for entering the fetched instruction in the instruction fetch queue <b>208</b>. The short identifier allows fast decoding for identification of coprocessor instructions in the instruction fetch queue <b>208</b>. The instruction fetch queue <b>208</b> utilizes pointers to control and coordinate forwarding coprocessor instructions to the coprocessor <b>206</b> and issuing instructions to the processor <b>204</b>. The action of copying an instruction from the instruction fetch queue <b>208</b> and forwarding the instruction to the coprocessor is called transiting the instruction. For example, a first pointer may be used to indicate which instruction in the instruction fetch queue <b>208</b> is the oldest instruction not transited to the coprocessor <b>206</b>. A second pointer may be used to indicate which instruction in the instruction fetch queue <b>208</b> is the oldest instruction not yet issued to the processor <b>204</b>. Control logic in the instruction fetch queue <b>208</b> uses the first pointer, valid bits, and position of the instruction being accessed from the instruction fetch queue <b>208</b> to select, for example, up to the next four coprocessor instructions. Generally, each entry in the instruction fetch queue (<b>208</b>) has a “valid bit”. These valid bits are attributes that are used by control logic to determine whether an entry has a valid instruction which may be selected for further processing. An entry is invalid initially, because no instruction has been fetched into that location, or a valid entry may become invalid if the instruction associated with that entry needs to be flushed out of the instruction fetch queue <b>208</b>. It is appreciated that four instructions in a packet may be accessed for execution on the processor <b>204</b> or coprocessor <b>206</b> depending on the short identifier stored with the encoded instruction in the instruction fetch queue <b>208</b>. A packet of processor instructions are generally decoded and issued to the execution pipelines <b>218</b> in parallel. Since architecturally a packet is not limited to four instructions, more or less than four instructions may be fetched, issued and executed in parallel depending on an implementation and an application's requirements.

The processor complex <b>200</b> may be configured to execute instructions under control of a program stored on a computer readable storage medium. For example, a computer readable storage medium may be either directly associated locally with the processor complex <b>200</b>, such as may be available from the L1 I-cache <b>210</b>, for operation on data obtained from the L1 D-cache <b>212</b>, and the memory system <b>214</b>. A program comprising a sequence of instructions may be loaded to the memory hierarchy <b>202</b> from other sources, such as a boot read only memory (ROM), a hard drive, an optical disk, or from an external interface, such as a network.

The coprocessor <b>206</b> includes, for example, a coprocessor instruction selector for transit <b>224</b>, a hybrid instruction queue <b>225</b>, and a coprocessor execution complex <b>226</b>. The coprocessor instruction selector for transit <b>224</b> may comprise a plurality of multiplexers whose outputs may be coupled to a set of posting registers <b>209</b> according to pipeline requirements of the processor <b>204</b>. A coprocessor select circuit <b>223</b> operative to control the coprocessor instruction selector for transit <b>224</b> generates selection signals to access the coprocessor instructions from the instruction fetch queue <b>208</b>. The plurality of multiplexers select one or more coprocessor instructions from the instruction fetch queue <b>208</b> skipping over intermixed processor instructions. The number of coprocessor instructions selected depends in part upon availability of space to receive the instructions in the hybrid instruction queue <b>225</b>. The number of coprocessor instructions that are transited from the instruction fetch queue <b>208</b> is kept track of through operation of coprocessor pointers. For example, an end pointer is incremented by the number of coprocessor instructions transited accounting for a posting register, such as posting registers <b>209</b> if it is required by pipeline operations. A start pointer is decremented by the number of coprocessor instructions selected from the instruction fetch queue <b>208</b>.

The hybrid instruction queue <b>225</b> comprising an in-order FIFO queue <b>228</b>, an out-of-order queue <b>229</b>, with a queue and hazard control circuit <b>230</b> configured to manage both queues. Coprocessor instructions are selected from the instruction fetch queue <b>208</b> out-of-order with respect to processor instructions and in-order with respect to coprocessor instructions. The hybrid instruction queue <b>225</b> is coupled to the instruction fetch queue <b>208</b> by means of the coprocessor instruction selector for transit <b>224</b>. The coprocessor instruction selector for transit <b>224</b> has access to a plurality of instructions in the instruction fetch queue <b>208</b> and is able to identify coprocessor instructions within the plurality of instructions it has access to for selection. The coprocessor instruction selector for transit <b>224</b> copies coprocessor instructions from the instruction fetch queue <b>208</b> and provides the copied coprocessor instructions to the hybrid instruction queue <b>225</b>.

In the hybrid instruction queue <b>225</b>, when instructions arrive as accessed from the instruction fetch queue <b>208</b>, the received instructions are stored in the out-of-order queue <b>229</b> if there is room therein. Otherwise, the instructions are placed in the FIFO queue <b>228</b> and are moved to the out-of-order queue <b>229</b> when there is space available in the OoO queue <b>229</b>. A multiplexer <b>231</b> is used to select a bypass path for instructions received from the coprocessor instruction selector for transit <b>224</b> or to select instructions received from the FIFO queue <b>228</b>, under control of the queue and hazard control circuit <b>230</b>. Dispatching, as used herein, is defined as moving an instruction from the instruction fetch queue <b>208</b> to processor <b>204</b> or to coprocessor <b>206</b>. Issuing, as used herein, is defined as sending an instruction, in a standard format, a decoded format, or an elaborated format for example, to an associated execution pipeline within processor <b>204</b> or within coprocessor <b>206</b>.

Coprocessor instructions are written to the OoO queue <b>229</b> in the order the coprocessor instructions are received. For a coprocessor having multiple execution pipelines, such as shown in the coprocessor execution complex <b>226</b>, the coprocessor instructions are read in-order with respect to their target execution pipelines, but may be out-of-order across the target execution pipelines. For example, CX instructions may be executed in-order with respect to other CX instructions, but may be executed out-of-order with respect to CL and CS instructions. In another embodiment, the execution pipelines may individually be configured to be out-of-order. For example, a CX instruction may be executed out-of-order with other CX instructions. However, additional dependency tracking may be required at the execution pipeline level to provide such out-of-order execution capability. The queue and hazard control circuit <b>230</b> checks for dependencies between instructions and controls instruction issue to avoid hazards, such as dependency conflicts between instructions. The out-of-order queue <b>229</b> is sized so that it is rarely the case that an instruction is kept from dispatching to the coprocessor execution complex <b>226</b> due to its being in the in-order queue when it otherwise would have been dispatched if the OoO queue were larger. In an exemplary implementation, the in-order FIFO queue <b>228</b> and out-of-order queue <b>229</b> are each sixteen entries with the coprocessor having coprocessor store (CS) issue pipeline <b>236</b> coupled to a CS execution pipeline <b>237</b>, a coprocessor load (CL) issue pipeline <b>238</b> coupled to a CL execution pipeline <b>239</b>, and a coprocessor function (CX) issue pipeline <b>240</b> coupled to a CX execution pipeline <b>241</b>. Also, a coprocessor register file (CRF) <b>242</b> may be coupled to each execution pipeline.

Coprocessor instructions, especially those for floating-point, SIMD, and other arithmetic operations, often require more pipeline stages to execute than processor instructions. This disparity can create performance bottlenecks when there are instructions which require synchronization between the processor and the coprocessor. For example, when the program flow in the processor is dependent upon a result in the coprocessor, that result should be provided with minimal delay so as not to throttle processor performance. Even without such dependencies, there is a performance advantage to starting coprocessor execution as soon as a coprocessor instruction has been detected in the instruction fetch queue, as this will minimize potential idle cycles in the coprocessor.

In a general implementation, issue logic examines instructions in an issue queue and issues instructions to a processor and to a coprocessor when there is no backpressure from the processor and the coprocessor indicating the instructions are able to be accepted for execution. Backpressure may be caused by the coprocessor having its execution pipeline filled such that the coprocessor cannot accept another instruction. In such a situation, the backpressure from the coprocessor would prevent issue of a processor instruction from the issue queue even if the processor could accept another processor instruction. Backpressure can also be caused by the processor which would prevent a coprocessor instruction from being issued even if the coprocessor could accept the coprocessor instruction. In such a situation, the backpressure from the processor would cause the coprocessor to be idle, where instead it could have made progress in executing the coprocessor instruction. Idle cycles are costly, both in terms of reduced performance and wasted energy. Thus, minimizing backpressure from either the processor or the coprocessor results in overall more efficient execution of code.

The present invention allows coprocessor instructions to be sent, or “transited”, to the coprocessor independent of the backpressure from the main processor. In so doing, the coprocessor can begin executing a coprocessor instruction before it would be considered as issued from the processor issue queue, such as the instruction fetch queue <b>208</b>. Even though coprocessor instructions are transited to the coprocessor <b>206</b> they are not removed from the instruction fetch queue <b>208</b>. The coprocessor instructions remain in the instruction fetch queue <b>208</b> to allow the processor <b>204</b> to track these coprocessor instructions for purposes of effectively maintaining program order, committing coprocessor instructions for execution, handling of instruction execution requiring operations from both the processor and the coprocessor, and handling flushes, for example. When the processor provides a commit indication for a coprocessor instruction, the processor has determined that the coprocessor instruction will not be flushed and the coprocessor can execute the coprocessor instruction. A coprocessor instruction can be flushed for a variety of reasons including, being in the path of a mispredicted branch, a data abort, an interrupt or the like. A conditional instruction is not flushed if it is determined by flag settings, for example to not execute. In this case, a non-executing conditional coprocessor instruction is executed as a no operation (NOP) instruction.

The processor <b>204</b> is generally responsible for ensuring instructions, including coprocessor instructions, complete execution in program order. In the coprocessor, the execution pipelines <b>237</b>, <b>239</b>, and <b>241</b> perform operations out-of-order with respect to each other. The hazard circuit <b>230</b> and an in-order retirement circuit <b>244</b> are used to ensure that the internally architected state is updated in program order. The processor <b>204</b> is configured to coordinate instruction execution between its pipelines and the coprocessor pipelines. The coprocessor is configured to access memory or peripherals through coordinated operations with the processor.

The processor <b>204</b> and coprocessor <b>206</b> essentially sync-up when there is a jointly executed instruction. For example, when executing a load instruction, the processor <b>204</b> calculates a memory address for data to be fetched, fetches the data from a memory, and sends the data to a coprocessor's load FIFO <b>416</b> of <figref idref="DRAWINGS">FIG. 4</figref>. The coprocessor <b>206</b> accepts the load data when it is available and then continues with the execution of instructions that are dependent on that data. The behavior is similar for stores except in this case the coprocessor <b>206</b> puts store data in a store FIFO <b>418</b> of <figref idref="DRAWINGS">FIG. 4</figref> and the processor <b>204</b> accepts it when it is ready. Moving data between registers in the processor <b>204</b> and coprocessor <b>206</b> is handled in a similar manner.

<figref idref="DRAWINGS">FIG. 2B</figref> illustrates exemplary coupling logic <b>250</b> between the processor <b>204</b> and the coprocessor <b>206</b> in accordance with the invention. The CS execution pipeline <b>237</b> comprises an execute circuit <b>252</b> and a store FIFO <b>254</b>. The processor execution pipelines <b>218</b> comprise circuitry to determine whether an issued coprocessor instruction is to be committed for execution, whether the issued coprocessor instruction requires attributes, such as an address, conditional information, or the like, and to generate an address for the issued coprocessor instruction when required. For an exemplary execution of a coprocessor store instruction, commit information <b>256</b> and attribute information <b>258</b> is sent to the CS execute circuit <b>252</b>. The information may be sent over separate signal lines or across a bus. Also, on the coprocessor, the commit information and the required attributes, once received, may be stored wherever the coprocessor instruction is located, such as, in the in-order queue, in the out-of-order queue, or in the CS execution pipeline <b>237</b>. Certain instructions are executed as a combination of separate operations on the processor <b>204</b> and on the coprocessor <b>206</b>. For example, a coprocessor store operation is a collaboration between the processor <b>204</b> and the coprocessor <b>206</b> CS execution pipeline <b>237</b>. The processor <b>204</b> performs address generation, permission checking and cache accessing, while the coprocessor <b>206</b> resolves data hazards, captures the data, performs necessary data processing, performs data alignment and signals the processor <b>204</b> that the data is available to be stored. For example, a data address for the coprocessor store instructions is generated in the processor execution pipelines <b>218</b> and selected through a multiplexer, such as multiplexer <b>262</b> to address the L1 D-cache <b>212</b>. The data for the coprocessor store instruction is selected from the store FIFO <b>254</b> and sent to the processor over bus <b>264</b> to a multiplexer, such as multiplexer <b>266</b> to be sent to the L1 D-cache <b>212</b>, for example over signal interface <b>268</b>. Often, the coprocessor execution steps take longer than the processor execution steps supporting execution of the same instruction. This embodiment allows the hiding of coprocessor latency behind delays in the processor due to the processor's own backpressure. In this case, the processor is causing the backpressure because it is backed up in its own execution pipes. An embodiment of the invention allows for the coprocessor to start executing coprocessor instructions, rather than becoming idle, in effect, hiding part or all of the latency of the coprocessor instruction execution.

The example illustrated in <figref idref="DRAWINGS">FIG. 2B</figref> for the execution of a coprocessor store instruction does benefit from embodiments of the invention in that execution of the store instruction advances in the coprocessor pipeline, even if the processor <b>204</b> is backed up. However, the benefit may in some situations be limited, since the execution of the store instruction cannot advance to the very end of the coprocessor pipeline before it receives certain attributes <b>258</b>, which the processor <b>204</b> can only supply after the store instruction has issued to the processor <b>204</b>.

There are other cases where the program flow in the processor <b>204</b> depends on arithmetic computations in the coprocessor <b>206</b>, which the coprocessor <b>206</b> can execute fully to the end of the coprocessor pipeline without needing any attributes from the processor. An example is execution of one or more long latency arithmetic instructions followed by execution of a dependent compare instruction in the coprocessor <b>206</b> and execution of a branch instruction in the processor <b>204</b> that depends on the result of the compare. In this example, the entire coprocessor instruction sequence including the compare instruction may be executed to completion before the branch instruction even needs to be issued. When the branch is eventually issued to the processor <b>204</b>, the compare result on which the branch depends would be already be available, effectively hiding all of the latency associated with the coprocessor instructions.

<figref idref="DRAWINGS">FIG. 3A</figref> illustrates a process <b>300</b> for queuing instructions in accordance with the present invention. The process <b>300</b> follows instruction operations in the coprocessor <b>206</b>. References to previous figures are made to emphasize and make clear implementation details, and not to limit the process to those specific details. At block <b>302</b>, a window of coprocessor instructions are identified in an instruction queue, such as the instruction fetch queue <b>208</b> of <figref idref="DRAWINGS">FIG. 2A</figref>, and transited to the coprocessor <b>206</b>. The window may be one to N instructions, depending upon the implementation. A window selection function in select circuit <b>223</b> selects the applicable class of instructions, coprocessor instructions in this case, and does not select other intermixed instructions, such as processor instructions. To transit the window of instructions, the N coprocessor instructions in the window are copied from the instruction fetch queue <b>208</b> and forwarded to the coprocessor <b>206</b>. At decision block <b>304</b>, a determination is made whether the window of instructions has been received from the fetch queue. If at least one instruction has not been received, the process <b>300</b> waits until an instruction is received. When the window of instructions is received, the process <b>300</b> proceeds to decision block <b>306</b>. At decision block <b>306</b>, a determination is made whether a queue, such as the out-of-order queue <b>229</b>, is full of coprocessor instructions. If the out-of-order queue <b>229</b> is not full, the process <b>300</b> proceeds to decision block <b>310</b>. At block <b>310</b>, the received window of instructions is stored in the out-of-order queue <b>229</b>. Since the window of instructions may be N instructions, N&gt;1, and the out-of-order queue <b>229</b> may have room for less than N instructions, the out-of-order queue is filled and the process <b>300</b> then returns to decision block <b>304</b> to process any remaining instructions from the window of instructions. If the out-of-order queue <b>229</b> has room for the window of N instructions, the N coprocessor instructions are stored at block <b>310</b>. The process <b>300</b> then returns to decision block <b>304</b> after storing the N instructions to wait till the next window of coprocessor instructions is received.

Returning to decision block <b>306</b>, if the out-of-order queue <b>229</b> is full, the process <b>300</b> proceeds to decision block <b>314</b>. At decision block <b>314</b>, a determination is made whether the in-order queue <b>228</b> is also full. If the in-order queue <b>228</b> is full, the process <b>300</b> returns to decision block <b>304</b> with the received window of coprocessor instructions pending to wait until space becomes available in either the out-of-order queue <b>229</b> or the in-order queue <b>228</b> or both. An issue process <b>320</b>, described below, issues instructions from the out-of-order queue <b>229</b> which then clears space in the out-of-order queue for new instructions to be received. Returning to decision block <b>314</b>, if the in-order queue is not full, the process <b>300</b> proceeds to block <b>316</b>. At block <b>316</b>, the received instruction is stored in the in-order queue <b>229</b> and the process <b>300</b> returns to decision block <b>304</b> to wait until the next window of coprocessor instructions is received.

<figref idref="DRAWINGS">FIG. 3B</figref> illustrates a process <b>320</b> for communicating information between the coprocessor <b>206</b> and the processor <b>204</b> in accordance with the present invention. At block <b>322</b>, the window of coprocessor instructions transited from the instruction fetch queue <b>208</b> in block <b>302</b> of <figref idref="DRAWINGS">FIG. 3A</figref> and still remaining in the instruction fetch queue are now issued to the processor <b>204</b>. At decision block <b>324</b>, a determination is made whether coprocessor attributes are required. If coprocessor attributes are required, the process <b>320</b> proceeds to block <b>326</b>. At block <b>326</b>, the required attributes are generated in the processor <b>204</b>. Example attributes provided by the processor <b>204</b> to the coprocessor <b>206</b> include memory alignment information for loads and stores and condition code evaluation for conditionally executed instructions. The memory alignment information for loads is needed to arrange the load data received from memory in a register aligned form prior to writing the load data to a target register. The memory alignment information for stores is needed to arrange the store data read from a register in memory aligned form prior to writing the store data into memory. The condition code evaluation for conditional instructions is needed to determine whether a coprocessor instruction is to be executed or not based on a condition code evaluation done in the processor <b>204</b>.

At block <b>328</b>, the generated attributes are sent to the coprocessor and the process <b>320</b> proceeds to decision block <b>330</b>. Returning to decision block <b>324</b>, if coprocessor attributes are not required, the process <b>320</b> proceeds to decision block <b>330</b>. At decision block <b>330</b>, a determination is made whether each of the coprocessor instructions can be committed for execution. Since the coprocessor instructions are accessed early prior to being issued to the processor, the program flow that was taken may not require the coprocessor instructions to be executed. However, it is generally expected that most of the early access coprocessor instructions are committed for execution. In such a general case, at block <b>332</b>, commit information is forwarded to the coprocessor.

The “window” of instructions is generally relevant in the instruction fetch queue <b>208</b>, where instructions within the window are being considered for issue or transit. Once instructions have issued or transited, the information that they issued or transited from within the same window is not relevant to their execution.

The execute/no-execute interlock between the processor <b>204</b> and the coprocessor <b>206</b> is based on a commit indication and a flush indication. The processor <b>204</b> sends the commit indication when the processor determines a particular instruction can complete execution. This is done in program order, so that the coprocessor <b>206</b> can appropriately mark the next instruction in program order as committed. This instruction can be anywhere in the coprocessor <b>206</b>. It is also possible for there to be a mix of committed and uncommitted instructions in the coprocessor <b>206</b>, but this is not an arbitrary mix. All uncommitted instructions are by definition younger, later in time in the program flow, than any committed instructions. When the processor <b>204</b> determines that the program flow has changed and there are instructions that were previously sent to the coprocessor <b>206</b> that should not be executed, the processor <b>204</b> sends the flush indication to the coprocessor <b>206</b>. When the coprocessor <b>206</b> receives this flush indication, it flushes away all coprocessor instructions that have not yet received a commit. The flush indication is also used in the processor <b>204</b> to flush any uncommitted processor instructions. Coprocessor instructions that have received a commit are kept and executed.

<figref idref="DRAWINGS">FIG. 3C</figref> illustrates a process <b>340</b> for updating coprocessor instructions within the coprocessor based on information generated in the processor in accordance with the present invention. At block <b>342</b>, the coprocessor monitors for commit and attribute information. At decision block <b>343</b>, a determination is made whether a commit or attribute information has been received for each instruction of the N coprocessor instruction window. If a commit or attribute information has not been received for each of the N coprocessor instructions, the process <b>340</b> returns to block <b>342</b>. If a commit or attribute information or both have been received for at least one of the N coprocessor instructions, the process <b>340</b> proceeds to block <b>344</b>. At block <b>344</b>, the received commit or attribute information or both are stored with the associated coprocessor instruction, for example, in the in-order queue <b>228</b>, in the out-of-order queue <b>229</b>, or in an associated execution pipe in the coprocessor execution complex <b>226</b>.

<figref idref="DRAWINGS">FIG. 3D</figref> illustrates a process <b>350</b> for issuing instructions in accordance with the present invention. At block <b>352</b>, a queue, such as out-of-order queue <b>229</b>, is monitored for instructions to be executed. At decision block <b>354</b>, a determination is made whether the out-of-order queue has any instruction entries. If there are no instructions to be executed in the out-of-order queue, the process <b>350</b> returns to block <b>352</b> to monitor the out-of-order queue. If at least one coprocessor instruction is identified in the out-of-order queue, the process <b>350</b> proceeds to decision block <b>355</b>. At decision block <b>355</b>, a determination is made whether an execution pipeline is available that can accept a new instruction for execution. If all the execution pipelines are busy, the process <b>350</b> waits until an execution pipeline frees up. When an execution pipeline is available to accept a new instruction for execution, the process <b>350</b> proceeds to decision block <b>356</b>. At decision block <b>356</b>, a determination is made whether the identified coprocessor instruction has required corresponding attributes. If it is determined that the required corresponding attributes are not available, the process <b>350</b> proceeds to block <b>357</b>. At block <b>357</b>, the identified coprocessor instruction is kept in the out-of-order queue until the required corresponding attribute/s are received. Generally, attributes are needed before a commit indication and attributes are generally needed in order to dispatch into the execution pipes. A coprocessor instruction may advance all the way to the end of a pipeline without having received a commit indication. However, the instruction is not allowed to update any architected resources, such as writing back a register file, until the corresponding commit indication has been received. Returning to decision block <b>356</b>, if the required corresponding attributes are available, the process <b>350</b> proceeds to block <b>358</b>. At block <b>358</b>, an instruction, stored in the out-of-order queue, is sent, avoiding hazards such as dependency conflicts between instructions, to an available issue pipeline. If more than one issue pipeline is available, multiple instructions without dependencies from the out-of-order queue may be dispatched out of program order across multiple separate pipelines. If multiple instructions are destined for the same execution pipeline, those instructions may remain in program order. The process <b>350</b> proceeds to decision block <b>359</b>. At decision block <b>359</b>, a determination is made whether the one or more coprocessor instructions have a required corresponding commit indication. If a particular coprocessor instruction has not received a commit indication the process <b>350</b> proceeds to block <b>360</b>. At block <b>360</b>, the pipeline associated with the uncommitted instruction is stalled until the commit is received. Returning to decision block <b>359</b>, if corresponding commit indications have been received, for those associate pipelines, the process <b>350</b> proceeds to block <b>361</b>. At block <b>361</b>, the architected resources associated with committed and executed coprocessor instructions are updated. The process <b>350</b> then returns to block <b>352</b>.

Once an instruction or instructions are dispatched from the out-of-order queue, space is freed up in the out-of-order queue. New instructions or instructions from the in-order queue may then be stored in the out-of-order queue in preparation for execution, following the queuing process <b>300</b> described above. The process <b>350</b> proceeds to decision block <b>360</b>.

<figref idref="DRAWINGS">FIG. 3E</figref> illustrates a process <b>370</b> for moving instructions from the in-order queue to the out-of-order queue. Whenever there is space in the out-of-order queue, and one or more instructions exist in the in-order queue, those instructions are moved to the out-of-order queue. At block <b>372</b>, the process <b>370</b> monitors the in-order queue. At decision block <b>374</b>, a determination is made whether an in-order queue, such as in-order queue <b>228</b>, has any entries. If the in-order queue does not have any instructions, the process <b>370</b> proceeds to block <b>372</b>. If the in-order queue has one or more instruction entries, the process <b>370</b> proceeds to block <b>376</b>. At block <b>376</b>, the one or more instructions stored in the in-order queue are moved to space available in the out-of-order queue. The process <b>370</b> then returns to block <b>372</b> to monitor the in-order queue.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary embodiment of a coprocessor and processor system <b>400</b> in accordance with the present invention. An n-entry instruction queue <b>402</b> corresponds to the instruction fetch queue <b>208</b>. The coprocessor illustrated in <figref idref="DRAWINGS">FIG. 4</figref> is a vector processor having a vector in-order queue (VIQ) <b>404</b> corresponding to in-order queue <b>228</b> and a vector out-of-order queue (VOQ) <b>406</b> corresponding to out-of-order queue <b>229</b>. A vector store pipeline (VS) <b>408</b>, a vector load pipeline (VL) <b>410</b>, and a vector function execution pipeline (VX) <b>412</b> having six function computation stages (Vx<b>1</b>-Vx<b>6</b>). The VS, VL, and VX pipelines are coupled to a vector register file (VRF) <b>414</b> and collectively correspond to the coprocessor execution complex <b>226</b>.

A load FIFO <b>416</b> is used to keep load data received from the processor and acts as buffer storage between the processor <b>204</b> and the coprocessor <b>206</b>. This is advantageous in the case where the coprocessor is backed up and not yet ready to consume the load data, so the load data is written to the load FIFO to prevent the processor <b>204</b> from stalling. The store FIFO <b>418</b> is a similar buffer storage for store data going from the coprocessor <b>206</b> to the processor <b>204</b> and is advantageous in the case where the processor <b>204</b> is backed up and not yet ready to receive the store data, by holding the store data in the FIFO.

The methods described in connection with the embodiments disclosed herein may be embodied in hardware and used by software from a memory module that stores non-transitory signals executed by a processor. The software module may reside in random access memory (RAM), flash memory, read only memory (ROM), electrically programmable read only memory (EPROM), hard disk, a removable disk, tape, compact disk read only memory (CD-ROM), or any other form of storage medium known in the art. A storage medium may be coupled to the processor such that the processor can read information from, and in some cases write information to, the storage medium. The storage medium coupling to the processor may be a direct coupling integral to a circuit implementation or may utilize one or more interfaces, supporting direct accesses or data streaming using down loading techniques.

While the invention is disclosed in the context of illustrated embodiments for use in processor systems it will be recognized that a wide variety of implementations may be employed by persons of ordinary skill in the art consistent with the above discussion and the claims which follow below.