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
