The coprocessor can reject an instruction by bouncing it when it reaches the Issue stage. This can happen to an instruction that has been accepted as a valid coprocessor instruction by the decoder, but that is found to be unexecutable by the Issue stage, perhaps because it s to a non-existent register or operation.

If the coprocessor receives an instruction that is in the coprocessor extension space it must either execute or bounce the instruction. See Instructions which the coprocessor must bounce for more information.

When the bounced instruction leaves the Issue stage to move into Ex1, the token sent down the accept queue has its bounce bit set. This causes the instruction to be removed from the core pipeline.

When the instruction moves into Ex1 it has its dead bit set, turning it into a phantom. This enables the instruction to remain in the pipeline to match tokens in the cancel queue.

The core posts a token for the bounced instruction before the coprocessor can bounce it, so the phantom is required to pick up the token for the bounced instruction. The instruction is otherwise inert, and has no other effect.

The core might already have decided to cancel the instruction being bounced. In this case, the cancel token just causes the phantom to be removed from the pipeline. If the core does not cancel the phantom it continues to the bottom of the pipeline.