On 01/05/12 12:28, Steve Reinhardt wrote: > On Thu, Jan 5, 2012 at 9:40 AM, nathan binkert <[email protected]> wrote: > >>> SysModule sounds OK; I like SysObject too (more parallel with SimObject >> and >>> MemObject) though it is slightly more ambiguous than SysModule. I'd hold >>> off on finalizing a name until we get another opinion or two. >> I'm not sure that Module is less ambiguous than object. (Especially >> now that I write a lot of python code and a module refers to something >> else :) >> > Good point... > > >>> If we're going to keep the class, I'd prefer to keep the same name... one >>> of the main reasons I'd lean toward keeping the class is to minimize the >>> changes to the existing hierarchy, and changing the name loses that >> benefit. >> He who is the master of perl -pi -e 's/foo/bar/' ?! >> > I wasn't arguing this because it's hard to make sweeping changes... more to > avoid confusing people ("What happened to my old friend MemObject?")... > though I suppose our users are less intimate with these things than I think. > > >> To me, the object with both port and system should be MemObject (which >> really minimizes the amount of code that has to change) and the thing >> in-between should be something like SimObjectWithPort or PortedObject >> or something like that. > > You're right, that would avoid changing the base class in lots of places, > vs. avoiding changing the MemObject code itself (which is what I was > minimizing). > > The challenge is that there are a number of objects that have a system > param but don't have ports (I see at least IntrControl, SimpleDisk, and all > the Platform derivatives (T1000, Tsunami, etc.)), and if we leverage this > new base class to factor that out, then we have a lot of things deriving > from MemObject that aren't really memory objects. > > If we were real OO purists, we'd have SysObject and PortedObject both > derive directly from SimObject, and MemObject would derive from both of > them. However, though I'm probably not quite as dead set against MI as I > used to be, I'm not going to push over that easily. > > 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. There may be more instances than I'm thinking, but maybe they all already share a common ancestor like the Platform class. 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? Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
