The precommit mechanism is currently implemented by retirement calling the precommit method on various functional units and blocks. This had the problem (which we experienced previously) that having method calls in these methods can lead to performance issues, which we fixed by using a TryProduct. Still, the architecture seems somewhat backwards: the precommit methods are almost always called, in all the units at once - in a way, retirement "broadcasts" some information via a method.
A simpler way to achieve this would be to reverse the calling direction, which I did in this PR. The retirement module defines the precommit method, which is nonexclusive and called from functional units and blocks.
The change looks pretty much cosmetic, but I have in mind another change, which would slightly simplify the implementations of units and eliminate the error-prone rob_id comparisons.
The
precommitmechanism is currently implemented by retirement calling the precommit method on various functional units and blocks. This had the problem (which we experienced previously) that having method calls in these methods can lead to performance issues, which we fixed by using aTryProduct. Still, the architecture seems somewhat backwards: theprecommitmethods are almost always called, in all the units at once - in a way, retirement "broadcasts" some information via a method.A simpler way to achieve this would be to reverse the calling direction, which I did in this PR. The retirement module defines the precommit method, which is nonexclusive and called from functional units and blocks.
The change looks pretty much cosmetic, but I have in mind another change, which would slightly simplify the implementations of units and eliminate the error-prone
rob_idcomparisons.