nathan binkert wrote: >> 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... >> > > It turns out that I had forgotten about the relationship between > ThreadContext, ExecContext, and registers. I had a chance to discuss > this with Steve and Gabe today and Gabe has agreed to write something > up to describe how to solve this problem cleanly across the CPU > models. I think that part of the problem is that the register file > shouldn't really be defined in the ISA, and the ExecContext needs a > consistent way for accessing registers. We'll probably end up with > new functions for accessing registers from other threads instead of > modifying the existing ones. Hopefully one of the things that will > fall out of this work is consistent, working thread support across the > various CPU models. > > Nate > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev Just to make sure everyone's on the same page, I agreed to write something up to describe how the ISA defined register file and the CPU defined register file can coexist and cooperate peacefully, plus I'll tack on one or two other ideas I've been kicking around for a while. I hadn't planned on addressing the actual function calls that get at the registers, but hopefully by straightening out the rest of it that becomes easier.
Gabe _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
