Sequence of result and commit interface transactions

[christian-herber-nxp]

I would like to discuss the following part of the specification

A coprocessor is only allowed to provide a result for an instruction once the core has indicated (via the commit interface) that this instruction is allowed to be committed.

As CPUs become more complex, issuing multiple instructions, the chances get significantly higher that copro instruction complete execution before being committed. This will stall the pipeline quite a bit. Allowing instructions to writeback the result before being committed can solve this. What the CPU does with this is secondary. It could use the result within a reorder buffer.

Of course, it is a parameter of the CPU if it is able to deal with results being written back before they are committed. On the other hand, this does take away complexity from the coprocessor, especially if it doesn't have state of its own.

Looking forward to your input.

[Silabs-ArjanB]

Allowing instructions to writeback the result before being committed can solve this.

This would then put all the complexity on the CPU, which would be a no go for low-end CPUs.

Of course, it is a parameter of the CPU if it is able to deal with results being written back before they are committed.

I don't think we can make that a parameter. If a CPU does not unconditionally needs to support this write back for non-committed instructions, then we will end up with coprocessors that are incompatible with such CPUs.