> For #1 and #4, these are pretty much the same right? The contextID is > really all possible sharers rather then just threadContext. Seems like you > should keep the meaning of contextID as it pertains to thread and then > generate a "sharerID" that would be a superset of the contextIDs. Objects > that dont have an explicit thread but are sharing can just offset off the > highest contextID. would that make sense? Yeah, I guess #1 and #4 were more or less the same as written. What I'd really like to know is if we should have just one ID or two. I'd personally rather stick with one. Maybe we just call it memoryAccessID or sharerID and the contexts would just use that. I'd really rather avoid adding IDs for the sake of adding IDs, but if it really makes sense, then we should do it.
> For #2, I'd prefer not to further complicate that ThreadContext interface. I'm not sure that it would complicate things much. The idea is to just put the things that are for memory requests into a base class and have thread context derive from that. So, not adding stuff, just splitting the class into two parts. > I thought the easiest way would be to use the port connections to traverse > the system since something is already done for the snoop Port > registration.The only trick would be for CPUs with multiple threads you need > to ask out how many contexts it's going to share. Yeah, it is doable. It would probably be nice to have a routine that is just designed to traverse the memory hierarchy and call a member function on every object in the hierarchy. I think registering with the system gets the same effect and is potentially simpler. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
