In order to make this messaging port, I actually found I could derive from SimpleTimingPort if I made two small changes. I commented out the assert at the top of recvTiming, and I made checkFunctional virtual so I could override it and always return false. I should mention I haven't finished working on it so there's a chance it won't work out for some reason. This seems like something that would be handy any time you wanted to work with the message passing structure of the memory system without having to use the shared memory abstraction on top of it, but the only case I can think of off the top of my head where that's useful is interrupts. I could easily move the port class into the IntDev class if people think that's best. I don't care if it's available generally or if it's only for interrupts. I'm going to arbitrarily keep working with it external to IntDev so I can get other things closer to working.
Gabe Steve Reinhardt wrote: > If existing Port subclasses don't provide anything you need, and you > don't expect any other devices to need their functionality, then > there's no need to declare a new port class outside of the interrupt > controller class... in fact when we first started using ports, each > device generally created its internal Port subclasses by deriving > directly from Port; it was only when we saw that there were recurring > patterns that could be successfully abstracted that we started > creating things like SimpleTimingPort. > > In fact, Port subclasses don't have to do anything except redirect the > receiveFoo() calls to the right methods in the enclosing device object. > > Steve > > On Sat, Sep 6, 2008 at 7:39 PM, Gabe Black <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > nathan binkert wrote: > >> Also the DmaPort doesn't send it's packets marked uncachable > which we > >> established as being a requirement for the interrupt messages. > I don't > >> -want- to have to write a new port type, but what I need is > >> fundamentally not a DMA transfer. Making the DmaPort the > solution for > >> things other than DMA is misleading, and not having it work for > other > >> things means I need to find a different solution. But like I > said, I > >> don't want to have to create a new port type, so I certainly > wouldn't > >> mind finding a way to use something that already exists. > >> > > > > I see the issue you're having now. That makes sense not to pollute > > the DmaPort with this sort of thing. I think the answer is to > create > > a new port type. You should be able to derive from SimpleTimingPort > > to significantly simplify your implementation. If not, we should > > clean up SimpleTimingPort so that it does work for this sort of > thing. > > > > Nate > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/mailman/listinfo/m5-dev > > > I just looked over SimpleTimingPort again, and there are two > deficiencies I saw. First, it only expects requests and only sends > responses. I don't know how much it would complicate things to make it > do both, but I suspect it'd have to make more assumptions about how > things are prioritized, how to handle nacks, etc. Second, functional > packets update other packets which overlap. This is an issue because > we're not writing to an array of storage locations, we're sending a > message to a device at some address. Also, there probably shouldn't be > functional accesses to the ports that accept interrupts anyway which > might simplify things. > > What might make sense, and make life easier all around, is to make > a new > type of port who's whole purpose in life is to send and receive > messages. You'd have a function that sent a message to an address/port > somewhere else, and when it got there it would call a call back on the > target. The messages should never interact which should make > things simpler. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/mailman/listinfo/m5-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
