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]> 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] > > http://m5sim.org/mailman/listinfo/m5-dev > > > Unless someone says otherwise, I'm adding it. > > Gabe > _______________________________________________ > 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
