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). 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
