We've got a lot of pending changes that fix issues like this in O3. I wouldn't
put a lot of effort into it until we get out patches sorted out and thing might
just go away.
Ali
On Oct 19, 2010, at 7:31 PM, Gabe Black wrote:
> I've just been poking around in O3, and the way it's handling delayed
> translation is looking pretty suspicious. The initiateAcc function
>
> The executeStore function in lsq_unit_impl.hh is the only place
> initiateAcc is called in O3. This is actually a wrapper function which
> calls the initateAcc function on the staticInst inside.
>
> Fault store_fault = store_inst->initiateAcc();
>
> if (storeQueue[store_idx].size == 0) {
> DPRINTF(LSQUnit,"Fault on Store PC %s, [sn:%lli],Size = 0\n",
> store_inst->pcState(), store_inst->seqNum);
>
> return store_fault;
> }
>
> assert(store_fault == NoFault);
>
> What I think is going on here is that O3 expects if the store queue
> entry was initialized must not have caused a fault, so go ahead with
> execution.
>
> If you look for translateTiming, the only place that's called by
> initiateTranslation in base_dyn_inst.hh which is called by readBytes and
> writeBytes.
>
> if (TheISA::HasUnalignedMemAcc) {
> splitRequest(req, sreqLow, sreqHigh);
> }
> initiateTranslation(req, sreqLow, sreqHigh, NULL, BaseTLB::Read);
>
> if (fault == NoFault) {
> effAddr = req->getVaddr();
> effAddrValid = true;
> fault = cpu->read(req, sreqLow, sreqHigh, data, lqIdx);
> } else {
>
> The callback used for when translation is finished is finishTranslation:
>
> template<class Impl>
> inline void
> BaseDynInst<Impl>::finishTranslation(WholeTranslationState *state)
> {
> fault = state->getFault();
>
> if (state->isUncacheable())
> isUncacheable = true;
>
> if (fault == NoFault) {
> physEffAddr = state->getPaddr();
> memReqFlags = state->getFlags();
>
> if (state->mainReq->isCondSwap()) {
> assert(state->res);
> state->mainReq->setExtraData(*state->res);
> }
>
> } else {
> state->deleteReqs();
> }
> delete state;
> }
>
> So if translation finishes immediately, the fault gets set in
> finishTranslation iniline with the initiateTranslation call, and when
> you get back to readBytes/writeByte you can check it. If not, the
> translation just cleans up after itself and disappears, and the fault is
> lost.
>
> Am I interpreting this correctly? Is this broken, or am I just missing
> some element that makes it work? Making this work correctly would make
> implementing my initiateAcc commits change easier because then the
> faults from executing initiateAcc and translation are clearly separated,
> not mushed together like they are now.
>
> Gabe
> _______________________________________________
> 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
