Korey,
That idea of creating a fault was probably leading to a dead lock, as you
stated. Then, trying to stall the access as suggested, I added constraints
between stores in the Instruction Queue (actually inside MemDepUnit), where
only membar constraints were handled before. The simulator executed without
problems.
Code in MemDepUnit<MemDepPred, Impl>::insert(DynInstPtr &inst)
...
} else {
producing_store = depPred.checkInst(inst->instAddr());
}
if (inst->isStore() && store) { // Add new constraint
if(producing_store == 0) {
producing_store = storeSN;
} else {
producing_store = (storeSN > producing_store ? storeSN : producing_store);
}
}
...
But I need to find the point to log order of completion of loads and stores
in the LSQ (between LSQ and L1 cache), to check the effect of that change.
I was observing inside LSQUnit<Impl>::completeDataAccess(PacketPtr pkt).
But the order observed doesn't look like the expected.
I wonder if I'm observing the right place...
Thank you,
--
Eberle.
On Tue, Feb 1, 2011 at 3:31 AM, Korey Sewell <ksew...@umich.edu> wrote:
> 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 <rambo.u...@gmail.com> 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 <rambo.u...@gmail.com> 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 <ste...@gmail.com>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 <rambo.u...@gmail.com> wrote:
>>>>
>>>>> Any ideas?
>>>>>
>>>>> On Fri, Jan 21, 2011 at 5:00 PM, Eberle <rambo.u...@gmail.com> 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
>>>>> 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
>>
>>
>
>
> --
> - Korey
>
> _______________________________________________
> 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
