On Wed, May 25, 2011 at 10:57 AM, nathan binkert <[email protected]> wrote: > > I see a few options for solving this problem: > 1) Separate out the contextId allocation from registerThreadContext so > things like DMA controllers and memtesters can get allocated a > contextID. > 2) Create a base class for ThreadContext that is far simpler than the > current thread context and use that when registering. > 3) Figure out contextID not by registration, but instead by doing a > traversal of the memory system. This would require that we have some > sort of indication differentiating memory objects that can generate > requests and thus require a contextID and memory objects that can't > (caches, dram, pio devices, etc.). We add a constructor parameter to > the MemObject base class. > 4) Add a separate registration function for non Thread Contexts.
While #3 sounds nice, it's a relatively big change, and would have to be done in a way that works both for the m5 classic memory system and for Ruby, and ideally is robust and predictable in assigning contextIDs in the face of minor configuration changes. My guess is that it will end up being harder than it sounds... maybe Korey can speak up if his experience indicates otherwise. The others seem more reasonable, but possibly still overkill. The idea I had, that's kind of a hack but combines #2 and #4 in a degenerate sort of way, would be to allow non-ThreadContext objects to call registerThreadContext, but they would pass in NULL for the ThreadContext pointer. This would allow something like a DMA device or the memtester to reserve or allocate a context ID without being a ThreadContext, but without creating an additional base class. The only down side I see is that error tracking would be harder; if two non-ThreadContexts tried to claim the same ID, the System would not have a pointer to be able to identify the first one. Basically that's the only case I can see where it would be useful for the System object to hold on to some kind of pointer for something that's not an actual ThreadContext. Of course, the current ThreadContext pointers don't have any real debug info either, so even now you just get "Cannot have two CPUs with the same id (%d)\n" when you try to reuse a context ID, so apparently it hasn't been a big problem. If we cared about providing good error messages, we could extend registerThreadContext to take both a SimObject* and a ThreadContext* and track both of these, but make the latter optional. This would provide better error messages for everyone (though again, this hasn't been a problem that I've seen). registerThreadContext is only called from one place (BaseCPU::registerThreadContexts()) so it wouldn't be hard to change that. Just some ideas... Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
