On Nov 5, 2008, at 2:01 AM, Gabe Black wrote: > Looking into this more, there are two problems. First, it looks > like > Alpha is passing back it's store conditional result in the extra data > part of the request. I think for regular swaps this is actually the > data > to swap in, and for conditional swaps this is what to compare to, but > I'm not absolutely sure. In any case, what to do with this value to > split it up is very ambiguous, so I'm just going to panic on any > spit swap. Ok... that seems fine, I doubt there are many split swaps anyway. > > Second, handleLockedWrite is called on any swap, but it isn't until > later, and only for conditional swaps, where that extra data field is > actually set to anything. That means that in all cases you're actually > trashing something useful, and for conditional swaps you're actually > then loosing the value when you set the pointer to something real. I > tried rolling back my changes to timing.cc to make sure this wasn't > something I did accidentally and it appears not, but that still may be > the case. If nobody does anything with this for a while I'll get to > it, > but that might not happen quickly. I don't understand anything that is said in this paragraph. Could you elaborate a little bit.
Ali > > Gabe > > Steve Reinhardt wrote: >> You're right, it is the request and not the packet... that's what I >> get for answering off the top of my head. The packet pointer is >> what's passed back to completeAcc() I believe just because loads and >> stores both share the same interface and loads need the packet >> pointer >> to get the response data. >> >> At least for store conditional, the result is really a status >> rather a >> value, so the most general approach would be to have a function that >> combines the status values from the split requests into a final >> status. If we can define a function that works for all instructions >> that care about the status value then that might not be too bad. >> Given that store conditional may be the only thing that cares, it >> shouldn't be hard to define a function that works for now, >> particularly if it never gets called. Either "assert that both >> status >> values are equal" or "bitwise OR" would probably work. I'm not sure >> which one is more likely to work in the future, but probably all we >> can do is pick one at this point and then if the need ever arises to >> actually use it then we can revisit the issue. >> >> I'd lean toward "assert that both status values are equal" because >> it's less likely to have some subtle failure mode that leaves us >> scratching our heads until we recall this conversation. >> >> Steve >> >> On Sun, Nov 2, 2008 at 5:35 PM, Gabe Black <[EMAIL PROTECTED]> >> wrote: >> >>> Ok. really the result is being passed in the request and not the >>> packet, >>> right? There are several things that make this tricky. The request >>> in >>> this case would need to reflect whether or not the call to >>> handleLockedWrite worked, but it would also have to potentially be >>> broken into two parts for a split access. Which request do you give >>> back? The original one for the whole write, or the partial one you >>> actually used? Which half? The first one or the one that failed? >>> Which >>> packet do you use to carry the result back to completeAcc? I think >>> a lot >>> of things could work here, but nothing is clearly the right >>> answer. The >>> immediate reality is that nothing we have uses both the locked >>> accesses >>> and unaligned/split accesses, but I REALLY don't design something >>> where >>> that's not possible. I'll eventually need to properly support locked >>> accesses at some point, so I may need to use this mechanism in >>> x86. We >>> need to pick a set of semantics so that this sort of thing can be >>> handled consistently and sensibly everywhere, so that instructions >>> know >>> what they can/can't expect, etc. >>> >>> Gabe >>> >>> Steve Reinhardt wrote: >>> >>>> You need to always call completeAcc() because it may do something >>>> necessary... in the case of store conditional, it updates the >>>> destination register that indicates to the program whether the >>>> store >>>> succeeded or not. completeAcc() gets this information out of the >>>> packet, so that's why you need to have one to pass to it if you >>>> don't >>>> actually call the cache. completeAcc() doesn't care whether the >>>> request made it to the cache or not. >>>> >>>> Steve >>>> >>>> On Sun, Nov 2, 2008 at 12:00 AM, Gabe Black >>>> <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>> I have split reads working (I think), and now I'm starting in on >>>>> writes. The write function is a little more convoluted than the >>>>> read >>>>> function, partly because it tries to always have a dcache_pkt >>>>> around >>>>> even when there hasn't been an access since that's passed to >>>>> completeAcc. The only time completeAcc is called inline with >>>>> initiateAcc, which is where read/write is called, is if the CPU >>>>> is still >>>>> running, aka not waiting for the dcache, and there was no fault. >>>>> The >>>>> only way this can happen is if either the instruction itself >>>>> never did >>>>> an access, which can be the case with ARM apparently, or if the >>>>> instruction is a store conditional which tried to do an access but >>>>> failed for some reason before the actual packet got sent. In >>>>> both of >>>>> these cases, rather than make sure that some nonsense dcache_pkt >>>>> is >>>>> around so completeAcc doesn't get a NULL pointer, would it make >>>>> sense to >>>>> just not call it at all? The Alpha memory instructions are a >>>>> little too >>>>> tangled for me to be confident whether that would be ok. It >>>>> looks like >>>>> they're actually made up of a few instructions? >>>>> >>>>> Gabe >>>>> _______________________________________________ >>>>> m5-dev mailing list >>>>> m5-dev@m5sim.org >>>>> http://m5sim.org/mailman/listinfo/m5-dev >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> m5-dev mailing list >>>> m5-dev@m5sim.org >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>>> >>> _______________________________________________ >>> m5-dev mailing list >>> m5-dev@m5sim.org >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
