Scalar out-of-order pipelined core model

[hal-jones]

To maintain existing functionality, it might be moving existing units to a simeng::inorder namespace, and duplicating/creating out-of-order units in a simeng::outoforder namespace. The following changes to units will be needed to support a simple out-of-order model:

Decode
No longer reads registers or receives forwarded operands.

Rename (new)
Receives uops from decode. Looks up source operands in an allocation table, and allocates free physical registers for destination operands, stalling if none are available. Scoreboarding flags allocated registers as not ready.

Dispatch/Issue (new)
Reads uops from rename, adding them to a reorder buffer (and assigning a sequence ID), reading ready source operand registers, and placing them in the reservation station. Receives forwarded operands from execute, and picks ready operands for issue to execution.

Execution
Results are forwarded to dispatch/issue instead of decode.

Writeback
Written uops are flagged as ready to commit, and destination registers are flagged as ready.

In addition, the following changes to the main Core behaviour will be needed:

Committing
Each cycle the head of the ROB may be committed if ready. Any allocated destination registers are freed.

Flushing
The sequence ID of instructions is used to loop over the ROB and mark younger instructions as flushed (and thus ignored when encountered later). Early pipeline stages (Fetch->Rename) are still flushed in full, as all entries are implicitly younger. Correct register allocation state must be reconstructed, as the valid (committed) mapping of architectural -> physical registers would be lost otherwise. The prototype simulator does this by keeping a "commit table" of architectural to physical register mappings, and "replaying" the allocation of non-flushed destination registers on top of this; this is probably expensive, and there are likely better and more accurate ways of doing this.