Quoting Korey Sewell <ksew...@umich.edu>: > So my original point (that obviously wasnt conveyed very well) was > more trying to re-work how this STL_C case works rather than kind of > patch it up so it works in the current framework. > > Seems to be me that completeAcc should never get called before > initiateAcc in any circumstance. I know that shortcut is because you > STL_C fails early, but even so, why cant it just finish like any other > instruction. What benefit are we gettiing from early completing it > (especially in a SimpleCPU)? Am I getting this fundamental issue? If > I'm not getting that wrong, then we can just fix the SimpleCPU to not > handle this special case in this fashion and all will be fine. > > So trying to play around with traceData in my opinion is the wrong way > to solve it. If you are going to do that, Nate's idea of writing the > traceData before the access sounds like it will work.But Gabe's way > works too, so whatever works there is fine with me. > > Long term, I'm just thinking that if I call initiateAcc and there is a > risk of completeAcc happening before it finishes seems like it breaks > the interface that the CPU/INST should use. And then in the future, > this is going to be a nasty bug that will trip somebody up (because > completeAcc might do something that screws things up early).
I agree with everything you've said here, except for one half thing and I've got a comment on one other. First, my change is actually doing what your saying. It's not mucking around with traceData, it's actually putting off calling completeDataAccess (which calls completeAcc) if we're in the middle of initiateAcc until we come out of it. That's the half. The other thing is the reason STC doesn't work like the other memory instructions. In those other cases where you're calling into memory, you're going to get a response some time later. When that happens, initiateAcc has since finished running and you can end up in completeAcc and be ok. When you don't have a delay in translation or when you go to memory, then there's no later point where you'll be doing anything for that instruction and you need to deal with it now. One completely different solution would be to do what you're saying and just not have the timing simple CPU work like it does. I think it's organized a lot like the atomic simple CPU because it used to be a part of it, but really a more natural organization would be as a state machine where activity was broken by hard lines into states. There might be a little more overhead that way, but it would make it much easier for non-experts to see what the heck is going on in there. It would also help the experts avoid introducing bugs because there are so many interactions to consider. Gabe > > On Tue, Apr 28, 2009 at 5:34 PM, nathan binkert <n...@binkert.org> wrote: >>>> What redirection? Or do you mean because traceData is protected in >>>> the simple CPU? You could, but then again, you could just make it >>>> public. Otherwise, I'm not sure what you're talking about. The >>>> execute function is generated for each cpu model separately and it >>>> knows the type. >>> >>> I'm talking about how there's the exec context, and then the proxy >>> exec context, and the thread context, and the simple thread context, >>> and the dyninst, and the etc. etc., and calls to, for instance, read a >>> register can travel through several layers before actually being >>> serviced. By making traceData a direct member of the very first exec >>> context interface, we're precluding passing it back to other layers >>> that may want some input. That's not to say I don't think it will >>> work, because I actually think it would, but it seems inconsistent >>> with how the rest of that interface goes together. >> I'm specifically talking about the parameter passed into the exec >> function which is either SimpleCPU or BaseDynInst. Those both have a >> traceData parameter and it can just be used directly without any fancy >> indirection. I am only talking about this code specifically. >> >>> Also this still doesn't address the fact that, one, completeAcc is >>> being called before initiateAcc has fully run, and two, that the trace >>> information is being printed before initiateAcc has written all its >>> results. >> Can't we just ensure that foo->traceData is set to NULL after it is >> deleted? Then the setData that's done in initiateAcc after the write >> won't complete. >> >> Also, looking at the code more closely, is there some reason taht we >> can't just move the setData line before the write? Wouldn't that >> solve the problem? It seems to me that the program wouldn't change >> since the contents of Mem should not change due to xc->write? >> (correct?) >> >> Sorry if I'm just being unhelpful. I don't know this code super well. >> >> Nate >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > > > > -- > =========== > Korey L Sewell > Computer Science & Engineering > University of Michigan > _______________________________________________ > 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
