FS... I'm not really up for rebasing much, so we need to get the prefetch stuff
handled and then I can get the latest set in and next on the list is the o3
stuff.
Ali
On Oct 20, 2010, at 12:09 AM, Gabe Black wrote:
> Great. I was thinking of adding a "translated" flag to the dyninst and
> then making commit wait for that, but it sounded suspiciously simple.
> Are you guys getting ARM to work on O3 for just SE, or FS too? I suppose
> if you need delayed translation that's for FS. Please let me know what
> other issues you've found so I know them if I see them. Any idea when
> you might start moving in O3 patches? After my PCstate patch I hope!
>
> Gabe
>
> Ali Saidi wrote:
>> 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
>>
>
> _______________________________________________
> 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
