If #2 didnt exist, then that would make more sense to me. That would make an instruction HAVE to use the threadContext interface to access any CPU facilities. That would also remove the CPU pointer from the instruction object as well.
If that were the solution, I would be OK with it, because then the CPU would be appropriately encapsulated away from an instruction's commands... On Fri, Feb 13, 2009 at 11:16 PM, nathan binkert <n...@binkert.org> wrote: > > My "toy" example of this is say I want to read a integer register from an > > instruction. I could either go: > > (1) inst->threadContext->readIntReg() > > or > > (2) inst->cpu->readIntReg() > > > > In the threadContext object, there is just some redundant call to > > cpu->readIntReg() anyway. So you end up calling (1) and (2) instead of > just > > directly calling (2). > > I think that's a holdover from before we had thread support. I'd > argue that #2 shouldn't exist. > > Nate > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > -- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
