Are your changes: 1) Causing the simulator to assert/panic/not function correctly. or 2) Allowing the simulator to work but giving you unexpected results (bad stats, etc.?)
If #2, it's a bigger picture issue and you'll need to add some debug statements in the code to make sure that stores are only seen in order (e.g. print out the sequence number for the instruction before a store is sent) If #1, you'll need to place some code blocking the store from going to the memory system. At some point, the instructions dependent on the store you just set to "not executed" will need the values from that store, so unless you are setting the store to "executed" at some point then a deadlock sounds like a probable issue. But also, you need to find where there is a "sendTiming" call in the o3 model or whatever function/code is executing the store and not execute it unless it's at the head of the queue. I havent looked at that code in awhile, so that's probably the best advice I could give for now, but judging from your last snippet, why would you need to create a fault if your store ordering is violated rather than just stall that access from initiating/executing/etc? I would think that the O3 has a choice of instructions to choose from in each IEW cycle, so why not just make the choice from the LSQ unavailable if something is out of order? What's the correct thing in HW to do there? Anyway, hope that helps... On Fri, Jan 28, 2011 at 12:12 PM, Eberle <[email protected]> wrote: > Steve, what about adding dependencies between stores in the Memory > Dependency Unit, should it do the trick or needs other modifications? > I've added the restrictions but the result wasn't the expected. Maybe I > need to make more changes in other places? > As I'm using SPARC, I'd need the processor to implement the TSO model, or > at least for now, to not allow reordering between stores. > > > Thanks in advance, > > -- > Eberle. > > > > On Tue, Jan 25, 2011 at 1:25 PM, Eberle <[email protected]> wrote: > >> Right, what I need is to prevent the reordering of stores. The stores >> should be executed in program order, the oldest store must be executed >> before a younger store is allowed to execute. >> Using O3 cpu and SPARC_SE. >> >> When the following code is put before 'store_inst->initiateAcc();' >> in LSQUnit<Impl>::executeStore(..) : >> >> if (store_idx != storeHead) { >> memDepViolator = storeQueue[storeHead].inst; >> ++lsqMemOrderViolation; >> return genMachineCheckFault(); >> } >> >> >> The following happens: >> >> >> M5 Simulator System >> >> Copyright (c) 2001-2008 >> The Regents of The University of Michigan >> All Rights Reserved >> >> >> M5 compiled Jan 25 2011 12:47:37 >> M5 revision 4c0f7929ee33+ 7842+ default tip >> M5 started Jan 25 2011 12:47:44 >> M5 executing on bellatrix >> command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b Helloworld >> -d >> Global frequency set at 1000000000000 ticks per second >> 0: system.remote_gdb.listener: listening for remote gdb on port 7000 >> 0: system.remote_gdb.listener: listening for remote gdb on port 7001 >> info: Entering event queue @ 0. Starting simulation... >> panic: Tried to access unmapped address 0x8. >> @ cycle 9577000 >> [invoke:build/SPARC_SE/arch/sparc/faults.cc, line 654] >> Memory Usage: 189360 KBytes >> For more information see: http://www.m5sim.org/panic/5932f339 >> Program aborted at cycle 9577000 >> Aborted >> >> >> In addition, I also tried not setting the store instruction as executed >> when a reordering case is detected in DefaultIEW<Impl>::executeInsts() : >> >> ... >> fault = ldstQueue.executeStore(inst); >> >> if(ldstQueue.violation(inst->threadNumber)){ >> // Don't set as executed >> activityThisCycle(); >> } else .... >> >> >> And this happens: >> >> M5 Simulator System >> >> Copyright (c) 2001-2008 >> The Regents of The University of Michigan >> All Rights Reserved >> >> >> M5 compiled Jan 25 2011 13:21:18 >> M5 revision 4c0f7929ee33+ 7842+ default tip >> M5 started Jan 25 2011 13:21:25 >> M5 executing on bellatrix >> command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b Helloworld >> -d >> Global frequency set at 1000000000000 ticks per second >> 0: system.remote_gdb.listener: listening for remote gdb on port 7000 >> 0: system.remote_gdb.listener: listening for remote gdb on port 7001 >> info: Entering event queue @ 0. Starting simulation... >> Exiting @ tick 9223372036854775807 because simulate() limit reached >> >> >> What can I do to prevent the reordering? >> >> Thanks, >> >> -- >> Eberle >> >> >> >> On Tue, Jan 25, 2011 at 12:37 PM, Steve Reinhardt <[email protected]>wrote: >> >>> Apparently not... >>> >>> When you say "it didn't work", what do you mean? Maybe if you ask some >>> more specific questions it will be easier for us to provide some clues. >>> >>> Steve >>> >>> On Tue, Jan 25, 2011 at 5:36 AM, Eberle <[email protected]> wrote: >>> >>>> Any ideas? >>>> >>>> On Fri, Jan 21, 2011 at 5:00 PM, Eberle <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> How can I enforce the reordering restriction between stores in the O3 >>>>> (W->W restriction)? To make an store to be executed only after all stores >>>>> issued before it were executed. >>>>> >>>>> I tried adding this condition in the executeStore method in >>>>> lsq_unit_impl.hh, but it didn't work: >>>>> >>>>> if (store_idx != storeHead) { >>>>> memDepViolator = storeQueue[storeHead].inst; >>>>> return genMachineCheckFault(); >>>>> } >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -- >>>>> Eberle Rambo. >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 > > -- - Korey
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
