Stall and Flush Counter (Initial Iteration)

[matms]

As per #174, I am opening a PR for adding a stall and flush counter.

However, note this PR is probably not quite mergeable yet. In particular, there are two "bugs", so we'd need to discuss how to fix these. In particular:

• An instruction is considered and counted as stalled or flushed when it reaches WB, rather than when it leaves WB. This diverges from the behaviour of instructionsRetired, which counts an instruction as retired upon leaving WB.

• The dual-issue processor currently considers only only one way for counting stalls and flushes. I suspect we might need a way to generically query a processor for which stages contain instructions that are about to be retired. Right now I'm using proc->stageInfo(proc->stageCount() - 1) to gather information about these instructions, which only works for the single ~~cycle~~ issue processors.

Once both these issues are resolved, we should be able to refactor instructionsRetired to be implemented in a manner similar to the stall and flush counter.

(Also, the diff for processortab.ui is quite messy... I hope this is not an issue)

[mortbopet]

which only works for the single cycle processors.

do you mean single issue processors?

I suspect we might need a way to generically query a processor for which stages contain instructions that are about to be retired.

I've considered whether we need to switch up the way that a stage reports its # of stages. By only having the ability to specify # of stages, we miss out on the processor telling about its structure, as in, # of issue slots/lanes. Which then restricts itself to single-issue processors. Instead, a processor could return a std::map<int, int> of specifying the lane # (key) and the stages in that lane (value). For the existing processors, this would be:

• single cycle: {(0, 1)}
• 5 stage: {(0, 5)}
• 5 stage: {(0, 6), (1, 6)}

This scheme could (potentially) also work for out-of-order processors which could be cool to eventually have in Ripes!
StageInfo would then follow this mapping, wherein it is indexed by a tuple of (lane, stage #). From there, it would then be up to the stall/flush counting mechanism to determine how to map this information to a counter. What do you think about this?

(Also, the diff for processortab.ui is quite messy... I hope this is not an issue) No worries, I'm assuming that you're using the UI Design tab in QtCreator, and so as long things look and act as expected, then all good!

[matms]

I've updated the flush and stall counter to use the new ProcessorStructure interface.

Sorry for the delay in updating, I've been quite busy the past few weeks.