I wish you'd have said something an hour ago ... :). Oh well. I think 2 sounds like a better option, and I -should- be able to adjust what I've got to fit that without too much arm twisting. I'll let you know if it becomes unworkable for some reason.
Gabe Steve Reinhardt wrote: > Actually I just saw your email this morning but didn't have time to > reply until now. > > Basically the issue is that now that we have callbacks, if you have > multiple outstanding requests then there's no way to easily associate > the callbacks with the requests, right? > > I'm reluctant to say the adding a requesterState field to the request > object is the right thing to do since (1) that's a pretty widely used > object and this is the only place it's needed (I think mostly because, > as you point out, just about everywhere else the Request is used as > part of the Packet and in that case you can use the Packet's > senderState instead) and (2) the Request is intended to be basically a > read-only static piece of information and not a smaller version of a > Packet. > > Is there a reason not to create the Packet object sooner, then send a > whole Packet to the TLB so that you can use the Packet's senderState > field? > > Another option would be to stick with passing in Request objects, but > add a separate explicit argument that gets returned with the callback > (basically the same as senderState, but not part of a class). The > nice thing about this approach is that you could keep the atomic TLB > translate calls the same (just taking Requests) and still be > relatively symmetric with the decoupled versions. (As opposed to > using Packets, where either you'd have to change the atomic calls too > or live with them being asymmetric.) > > Steve > > On Sat, Feb 21, 2009 at 11:52 AM, Gabe Black <[email protected] > <mailto:[email protected]>> wrote: > > Gabe Black wrote: > > I'm making good progress converting translation to allow > delays, but > > I've run into a snag when translations can be delayed and have to be > > split up across block boundaries. I keep track of the two packet > > components of a split access by using the sender state field of both > > packets. The CPU can check to see if both packets have come back > yet, > > and also have the larger packet that satisfies the original > request at > > the ready to hand back. For requests this is considerably harder > because > > there isn't any good way to track the same information. Does it seem > > reasonable to add a requesterState field to the request object? > > > > Gabe > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/mailman/listinfo/m5-dev > > > Unless someone says otherwise, I'm adding it. > > 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
