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