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
On 06/21/12, Ali Saidi wrote:
>
>
>
>
> It completely depends on what consistency model you're going for. The current
> code doesn't support sequential consistency, but the load-load ordering that
> is enforced is inline with ARMs ordering requirements.
>
>
>
> Ali
>
>
>
> On 21.06.2012 17:09, Dibakar Gope wrote:
>
> >
> > Hi All, I was skimming through the O3+Ruby portion of the current dev
> > repository code, that attempts to support load-load ordering for a stronger
> > consistency model. In existing code, L1 cache controller sends a
> > forward_eviction_to_cpu, which in turn set the hitExternalSnoop flag of a
> > load instruction (provided the load has not committed yet) through
> > checksnoop() function. The checkViolation() portion of the code says that
> > in order to be squashed and re-executed, that particular load instruction
> > has to see another supposedly older load that maps to the same cache block
> > (the first if () block). The code snippet is shown below: lsq_unit_impl.hh
> > checkViolations() ------------ if (inst_eff_addr2 >= ld_eff_addr1 &&
> > inst_eff_addr1 isLoad()) { // If this load is to the same block as an
> > external snoop // invalidate that we've observed then the load needs to be
> > // squashed as it could have newer data if (ld_inst->hitExternalSnoop) { if
> > (!memDepViolator || ld_inst->seqNum < memDepVi
olator->seqNum) { DPRINTF(LSQUnit, "Detected fault with inst [sn:%lli] " "and
[sn:%lli] at address %#x\n", inst->seqNum, ld_inst->seqNum, ld_eff_addr1);
memDepViolator = ld_inst; ++lsqMemOrderViolation; return new
GenericISA::M5PanicFault( "Detected fault with inst [sn:%lli] and " "[sn:%lli]
at address %#x\n", inst->seqNum, ld_inst->seqNum, ld_eff_addr1); } } //
Otherwise, mark the load has a possible load violation // and if we see a snoop
before it's commited, we need to squash ld_inst->possibleLoadViolation = true;
DPRINTF(LSQUnit, "Found possible load violaiton at addr: %#x" " between
instructions [sn:%lli] and [sn:%lli]\n", inst_eff_addr1, inst->seqNum,
ld_inst->seqNum); } else { --------------- --------------- In my understanding,
if a snoop hits a younger load in lsq before it is committed, it need to be
re-executed without any constraints from checkViolation() function to maintain
stronger consistency. I was talking about the following simple example: c0 c1
St B Ld A
St A Ld B if Ld B in core1 is executed out-of-order and later sees a snoop
before commit, should not we re-execute Ld B without any constraints from
checkViolations() function? Am I missing something completely over here?
Regards, Dibakar _______________________________________________ gem5-users
mailing list gem5-users@gem5.org <gem5-users@gem5.org>
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
