I forgot about swaps... I was in an Alpha-centric frame of mind. Maybe if we have to implement truly locked memory accesses for x86 (i.e., read-modify-write where the read, modify, and write are separate microops) then we should redo SPARC swaps using the same technique and get them out of the cache.
Steve On Tue, Nov 4, 2008 at 11:01 PM, Gabe Black <[EMAIL PROTECTED]> 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. > > 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. > > 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
