Glad to see that Gabe and Nilay are coming to agreement... just for posterity, I want to clear up a few things (though they probably don't have practical impact at this point):
On Tuesday, November 15, 2011, Nilay wrote: > Is it not possible that > only parts of the macro-op were fetched before the mode was switched, in > which case fetch in user mode would still create problem? Since the micro-ops are generated directly from the macro-op, and only the macro-op PC goes through the TLB, you always get all the micro-ops whenever you fetch a macro-op. So in the sense that matters here, no, you can't fetch only part of a macro-op. > > Even then, marking those microops non-speculative wouldn't fix the > > problem anyway. That would make O3 wait until they were at the head of > > the commit queue before executing them, but any branch could still > > easily be mispredicted. If you didn't execute a micro-op until all the micro-ops before it were ready to commit, than any earlier mis-predicted branches would be resolved before execution began. So I think it would fix the problem (though I agree with Gabe that it's not a desirable fix). This would also be tricky to implement; since micro-ops are only committed in bulk when a macro-op completes, micro-ops in the middle o a macro-op never really reach "the head" of the commit queue. > >> Serializing and being non-speculative are not the same thing and one > >> doesn't imply the other. I don't agree (though it doesn't really affect this discussion). Serialization does imply non-speculative execution, as I outlined above: if every instruction before you has completed, then none of them could still be in a speculative state to cause you any problems. The opposite is not true; it is possible to have non-speculative execution that does not imply serialization (though it's complicated, and in practice non-speculative execution often is achieved via serialization). > The properties of the macroop do not apply to > >> all the microops. Definitely true. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
