Quoting nathan binkert <n...@binkert.org>: >>> I think the difference is that passing it in explicitly means that >>> you could >>> keep it in a register for the duration of the function, and if you can put >>> it in a callee-save then maybe you could save a few dereferences. In >>> contrast the indirection would have to be repeated after every >>> function call >>> (which is exactly the behavior we'd be relying on here). >> >> Wouldn't we need to make it xc->traceData() to allow for all the >> redirection we've got in there? > > 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. > > Nate > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev >
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. 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. Gabe _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
