I'm running through all the regressions right now. I'll send out some patches before then in case anyone wants to review the changes before I push them. There was a little bit of weird behavior from 10.mcf in x86, but I only saw that once and I wasn't able to reproduce it so I don't know if it was actually a problem or if it was just an anomaly. I think it may have been because I stopped the test before it finished the time before and it got stuck with bad results somehow.
The changes I've made replace the translate(...) function in the TLBs with translateAtomic(...) which is basically the same as the old function, and translateTiming which uses a callback to defer completion if necessary. I've fully converted the timing simple CPU to use translateTiming, but everything else uses translateAtomic which behaves the same as the original function. None of the other timing CPUs support x86 yet, so that should be fine for now. Gabe Steve Reinhardt wrote: > It's safe for Translation::finish() to call "delete this" if that's > the last thing it does and if the caller (the TLB) doesn't use the > pointer again afterward. Does that solve your problem? Of course > that's the kind of constraint you'd definitely want to point out in > comments. > > On Sat, Feb 21, 2009 at 1:51 PM, Gabe Black <[email protected] > <mailto:[email protected]>> wrote: > > No problem. Now that I think about this more, I tried this and I > decided > not to go with it because it starts to get confusing how the different > components interact with each other. I have the callback > implemented as > a class called "Translation" with an overloaded "finish" function. > When > the translation is finished, the TLB calls that function, and then > whatever needs to happen to continue with the access happens. > Unfortunately, the Translation object needs to be statically allocated > or it ends up leaking memory. The code that knows what to do with a > Translation at the end of its life is called -through- the Translation > object, so it gets really dicey deleting it there. I also don't > want to > force the TLBs to know how to clean up a Translation. I added a > separate > "TranslationState" class which would be what you're suggesting in > 2, but > then it just seemed really ugly to have a Translation and a > TranslationState with a fairly subtle, unintuitive distinction between > them. I think the solution here could be as easy as renaming > Translation > to TranslationHandler or something like that, but I didn't pursue > it. I > will now unless you have a better suggestion. > > Gabe > > Steve Reinhardt wrote: > > 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] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > m5-dev mailing list > > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > 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
