yeah well during mis-predictions, interrupts etc. undoing that entire state (of name-mappings, and re-create a different one perhaps) might not be easy.
moreover, since it is running kind of a cycle ahead, it seems that this whole network, seems more like a cross-bar switch, for renames :)
On a conventional register-based OoO interrupts require issue replay and this is a major source of complexity and budget.
On the Mill, which is a "belt machine", interrupts are as far as the hardware is concerned just an involuntary function call; the Mill does result replay.
Regards mispredicts the Mill has a shockingly short pipeline and mispredicts (where the target is in cache) is only around 5 cycles or so. The Mill has a novel prediction mechanism called transfer prediction as covered in this talk http://millcomputing.com/topic/prediction/
Any thoughts about debugger support on the Mill? It seems to me that this could be a bit of a headache. For example, the usual technique for breakpoints is to trigger an interrupt at the desired instruction, which then causes a context switch to the debugger process. How will the debugger be able to access all the bypass-network/belt/spiller data?
My off-the-cuff thought is that since the spiller has a mechanism for dumping its state in memory anyway, there is probably (or should be) a way for software to force it to dump this state, which could be used by the debugger to read all the required data from a specified (probably model-specific) structure in memory.
moreover, since it is running kind of a cycle ahead, it seems that this whole network, seems more like a cross-bar switch, for renames :)