Sorry about that... I did see your email this morning but I had to go out before I got a chance to reply, and just got back home...
On Sat, Feb 21, 2009 at 1:36 PM, Gabe Black <[email protected]> wrote: > 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 >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
