Hi Dibakar,
I'm not saying that I believe this is correct for x86. It seems like x86 does require more ordering than is currently provided by the lsq. Hopefully someone with more x86 experience could chime in and confirm that. The faulting mechanism needs an overhaul in the o3 cpu. There shouldn't be any fundamental difference. Thanks, Ali On 27.06.2012 18:08, Dibakar Gope wrote: > Hi Ali, > > from this thread, http://www.mail-archive.com/gem5-dev@gem5.org/msg00782.html, I get an idea that a snoop invalidate will make a younger load and its following younger instructions to re-execute, if only an older load in the program order to the same cache block see an updated value. But I am not still sure, if it obeys the load-load ordering of a stronger consistency model other than ARM. Suppose for example, > C0 C1 > St A Ld C > St B Ld A > > In the above scenario, if the memory order becomes Ld A -> St A -> St B -> Ld C and if C1 receives an invalidation for cache block A, before Ld A make it to the front of the commit queue, still checkViolations() code won't squash the Ld A and any younger instructions to maintain strong consistency. > > My other doubt is that, can we make use of the squashDueToMemOrder() squash mechanism instead of using ReExec fault, if I want to squash the load A and younger instructions and re-fetch those again in the above scenario? ReExec waits for the faulted instruction to reach the front of the commit, is there any other fundamental difference of using ReExec in comparison to the squashDueToMemOrder() other than this? > > Thanks, > --Dibakar > > On 06/25/12, Ali Saidi wrote: > >> ARM just requires load-load ordering (which is stronger than alpha). x86 to my knowledge requires all stores in the system to be visible in the same order. Ali On Jun 22, 2012, at 11:50 PM, Nilay wrote: >> >>> What's the difference between ARM's load-load ordering and TSO? I am guessing in ARM not all instructions are flushed from pipe, but only those that are affected by the snoop. My understanding is that the O3 CPU flushes the entire pipeline when it sees that an instruction needs to execute again. Since instructions commit inorder, any load that gets squashed would mean that all subsequent loads are squashed as well. -- Nilay On Fri, June 22, 2012 8:47 am, Ali Saidi wrote: >>> >>>> HI Dibakar, I'd have to think carefully about it, but you may be right about TSO. I'd hope that someone who is more familiar with x86 could respond. Thanks, Ali On 22.06.2012 07:46, Dibakar Gope wrote: >>>> >>>>> Hi Ali, Thanks for the response. Ok, I got the point. I >>>> thought that since the O3 attempts to support the TSO for X86 , so inherently this enforces/covers the regular load-load ordering present in any stronger consistency model. But if it inline with ARM's requirements,then does it not violate x86 and TSO's conventional load-load ordering? >>>> >>>>> thanks, Dibakar >>> _______________________________________________ gem5-users mailing list gem5-users@gem5.org [1] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2] >> _______________________________________________ gem5-users mailing list gem5-users@gem5.org [3] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [4] > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users Links: ------ [1] mailto:gem5-users@gem5.org [2] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [3] mailto:gem5-users@gem5.org [4] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
