Right, the fault doesn't get ignored, but if the CPU handled it directly without having to return it from initiateAcc, it should work the same. What I was getting at in my review (assuming I actually wrote down what I was thinking) is that we could make initiateAcc always initiate a translation for later and then return and not have it do anything else. When the translation finished, it would get the request ready and sent out or handle any faults, and when that came back we'd be back to the way things are done now. That way we wouldn't have to do two passes and the functions could be a bit simpler.
What I thought you meant before was that the fault would be returned into the instruction object which would then do something with it. If that -was- the case, then we'd have to make sure initiateAcc returned any fault if there was one, and there'd be basically two ways for things to go depending on if translation was delayed. That doesn't seem to be the case, though. Gabe On 01/17/11 21:04, Ali Saidi wrote: > Exactly, and that fault is the fault from the tlb if there was a fault at > translation. > > Ali > > > On Jan 17, 2011, at 10:01 PM, Gabriel Michael Black wrote: > >> I looked at Alpha's ISA description briefly, and I didn't see anywhere an >> instruction did anything with the fault returned by a read/write in >> initateAcc other than return it. Do have an example where that isn't true? >> The only place I can think of where that would be useful is prefetches, but >> I think we already have a separate mechanism that handles that. >> >> Gabe > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
