On Mon, 2 Jan 2012, Steve Reinhardt wrote:
On Mon, Jan 2, 2012 at 11:20 AM, Nilay Vaish <[email protected]> wrote:
On Mon, 2 Jan 2012, Steve Reinhardt wrote:
Hi Nilay,
I think Gabe's point is that if you take the problem he is describing and
replace "misprediction" with "interrupt" then what you're seeing is just a
different manifestation of the same underlying problem. In a sense an
interrupt is just a control-flow misprediction, only much rarer and mostly
unavoidable... the pipeline predicts that control will always go to the
next sequential instruction for non-control-flow-instructions (and to
either the next instruction or the target for control-flow instructions)
and an interrupt is a situation where that prediction is wrong.
One difference is that in the branch misprediction case, the pipeline
immediately refetches along the correct path, while in the interrupt case,
the interrupt handler gets executed first, and the problem doesn't show up
until you return from the interrupt.
I think Gabe is also saying that if we did a larger restructuring of how
squashes are handled we could solve both problems at once (and perhaps
other related cases we haven't encountered yet). I agree that that sounds
good in theory, but in practice if there's a straightforward fix for the
current issue, I'm not opposed to putting that in.
Steve, from the way I have been able to fix the problem, it seems that the
issue is with the way interrupts are handled. As such I never saw squashing
being the problem, though it might be.
Step back a little... the problem you're having is in the way that
interrupts and squashing interact. You have fixed it by changing how
interrupts are handled, but it probably could also have been solved by
changing how squashing works (and I think that that was the direction you
were headed initially, talking about changes to the isSquashAfter flag).
I am not too confident that squashing working correctly can imply
interrupts are handled correctly. It might just work out. But as Gabe said
in one of his emails today, the condition for interrupt handling (instList
being empty) is broken. And this is independent of squashing.
Gabe is pointing out that there was an earlier, similar bug in the way that
branch mispredictions and squashing interacted, that probably also could
have been solved with changing how squashing works, in a way that probably
would have addressed your problem too.
I'm not saying anything about which solution is preferable, just trying to
get you and Gabe to see more eye-to-eye (and maybe get everyone else on the
same page too).
Steve, I don't think there is much to gain from this argument. We should
rather focus our energies on getting the O3 CPU to work correctly. In
fact, I need yours and everyone elses opinion on those other threads
(check pointing, interrupt handling) that are open. Let's just agree that
both squashing and interrupt handling mechanisms are broken and that they
need to be fixed.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
