Well, I'll admit that I've had a really hard time following this whole discussion. You could come over and we could actually spend a couple of hours discussing this if you like.
Nate On Thu, Sep 25, 2008 at 1:41 PM, <[EMAIL PROTECTED]> wrote: > There are multiple issues here, and I think they're getting mixed together. > Unfortunately this is complex enough that it's hard to explain in an email. > I'll try to explain it more fully sometime soon, hopefully with something more > expressive, although I don't know how much time I'll have before early next > week. Ideally we'd talk about this in person with a whiteboard, but that's > obviously not possible. > > Gabe > > Quoting Steve Reinhardt <[EMAIL PROTECTED]>: > >> I think maybe I got misled by the earlier discussion about keeping a pointer >> to the macroop in the thread context. Correct me if I'm wrong, but the >> issue now isn't really about that pointer. The issue is that when a series >> of microops from a single macroop reaches the head of the ROB, and one of >> those interior microops is marked as faulting, do I flush the preceding >> non-faulting microops from the same macroop before invoking the fault >> handler or not? >> >> If this is the problem, then it only applies to faults and not to >> interrupts, since as we've discussed you'll never get an interrupt in the >> middle of a macroop. >> >> You're saying that outside of this funky optimization for string moves (and >> maybe other instructions) then it's OK to always flush the microops. I >> agree. >> >> Thinking about it a little more, I'd bet it's always OK to flush the >> microops... looking at the string move case, you really don't care about >> restarting the macroop that faults (since that macroop represents only the >> last iteration of the REP)... what you really want to do is retry the entire >> macroop with the "safe" version of the microcode before you invoke the >> actual fault handler. >> >> So is it that simple? Or am I missing something? >> >> Steve >> > > > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
