On Fri, Jan 6, 2012 at 1:30 AM, Gabe Black <[email protected]> wrote:
> On 01/05/12 12:28, Steve Reinhardt wrote: > > > > So I think we're agreed on the hierarchy, and are down to three general > > naming conventions: > > > > 1. SimObject > PortedObject > SysObject > > 2. SimObject > PortedObject > MemObject > > 3. SimObject > MemObject > SysObject > > > > with minor variants where we substitute other new names for PortedObject > or > > SysObject (though those are my current favorites). > > > > #2 keeps existing children of MemObject as MemObject, but changes what > > MemObject is. > > #3 keeps the MemObject class itself unchanged, but requires reparenting > > current MemObjects to SysObject. > > > > In any case, objects that want to enjoy the inherited System param but > > don't need ports get stuck inheriting the port code anyway. I don't > have a > > problem with this. In case #2, those objects also end up being derived > > from MemObject, which seems odd since they're not in the memory system. > > Case #3 has a similar problem in that SysObject derives from MemObject > > even though not all SysObjects are in the memory system; somehow that's > > less objectionable to me because it only happens once. > > > > So maybe after all this I've talked myself into option #1... > > > > A fourth approach that comes to mind is to go with #2 above, but *not* > have > > other non-memory objects that want a System parameter derive from > > MemObject. Instead, as a separate task, we could add a SysObject that > > derives directly from SimObject but has the System param, and the objects > > that need the param but not ports could derive from that. It's not > elegant > > (I think I still prefer #1) but I could live with this. > > > > Sorry for the length here... mostly just thinking through this myself as > I > > type. > > > > Steve > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > I think there weren't very many places where the system pointer was > actually used, so making a whole class to avoid adding system parameters > where necessary seems like overkill. Sounds like an argument for my option #4 (which is really a variant of #2). I'm OK with that. > There may be more instances than > I'm thinking, but maybe they all already share a common ancestor like > the Platform class. As I said above, there's IntrControl and SimpleDisk that have system params and aren't derived from Platform. The only other case I can find is Process, which is sort of interesting in that it's not really a "system component" in the hardware sense. Certainly if we go with option #4 then a small improvement would be to put factor the system param out from all the Platform-derived objects into Platform itself. > Is it so they can check the memory system mode? Do > we really need that to be attached to the system object since it's > really global across the simulation? Memory mode is not global across the simulation. In a multi-system simulation it's perfectly OK to have one system in timing mode and the other in atomic. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
