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
