That sounds reasonable. I had originally envisioned this code having a use outside of the interrupt messages, or at least in objects that wouldn't inherit from IntDev to avoid multiple inheritance, etc, but if not then it doesn't need to be in its own class.
Gabe Quoting Steve Reinhardt <[EMAIL PROTECTED]>: > Hi Gabe, > > I haven't looked at all the code surrounding this in detail, but I think > this is unnecessary... packets really are messages (though up to now they've > all been coherence messages), and the idea behind Port objects is that in > the common case a MemObject should have a dedicated Port subclass that maps > virtual functions like recvAtomic() to non-virtual member functions of that > MemObject so that there's only one virtual function call on the path between > two objects. > > I suggest having IntDev::IntPort derive directly from SimpleTimingPort, move > MessagePort::recvAtomic() directly into IntDev::IntPort, and then get rid of > the MessagePort class entirely. > > Also I think that IntReq and IntResp (as you have in the comments in > packet.cc) are much more descriptive names than MessageReq and MessageResp. > > Steve > > On Sun, Oct 12, 2008 at 1:15 PM, Gabe Black <[EMAIL PROTECTED]> wrote: > > > changeset d2782c951841 in /z/repo/m5 > > details: http://repo.m5sim.org/m5?cmd=changeset;node=d2782c951841 > > description: > > Create a message port for sending messages as apposed to > > reading/writing a memory range. > > > > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
